スクラム-バックログをゆがめることなく、部分的に完成したユーザーストーリーを次のスプリントに引き継ぐ方法

私たちはスクラムを使用していますが、時折、それが計画されたスプリントでユーザーストーリーを完了できないことがあります。とにかく真のスクラムスタイルでソフトウェアを出荷し、次のスプリントプランニングセッション中に次のスプリントにユーザーストーリーを含めることを検討します。私たちが引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリントプランニングセッションでどのように正しく見積もることができますか？私達は考慮しました：

a）ストーリーポイントの数を減らして、ユーザーストーリーを完了するために残っている作業のみを反映するようにします。残念ながら、これは製品バックログの報告を台無しにします。

b）部分的に完了したユーザーストーリーを閉じて、新しいストーリーを作成して、ストーリーポイントの少ない残りの機能を実装します。これは、そのスプリントで完了しなかったものを遡及的に見る能力に影響し、少し時間がかかるようです。

c）aまたはbのいずれにも煩わされず、スプリントプランニング中に「ユーザーストーリーはXストーリーポイントかもしれませんが、95％が終了していることを知っているので、それが収まると確信しています。」

私の現在のチームではc）を行っています。

速度は、チームがスプリントで本当に完走したことを説明するものでなければなりません。配信されなかったものは顧客にとって価値がないため、ポイントを数えません。すべてか無かです。

したがって、未完成のストーリー全体を次のスプリントにシフトし、すべてのストーリーポイントが次のスプリントの速度に追加されます。速度は時間とともに均一になり、将来の速度の推定値を決定するための基準として、以前のいくつかのスプリントの平均を取ります。

オプションAは、一般的に推奨される一連のアクションです。前のスプリントのストーリーを完了し、ストーリーを製品のバックログに戻し、そこで優先順位が変更される場合、ポイントを付与しません。完成したユーザーストーリーと付加価値に基づいて、速度（およびその他のメトリック）を計算します。次のスプリントの計画を開始するとき、その価値に基づいて最も優先度の高いストーリーを採用します（ビジネスの優先順位が変更された場合、未完成のストーリーを含む場合と含まない場合があります）。ストーリーを見積もるときは、ストーリーの新しいポイント数を考慮に入れるときに、すでに行われた作業を含めます。

もちろん、別のオプション（および私の好み）は、ストーリーポイントの元の推定数を使用することです。これは私が過去に行ったことです。これは、見積もりが適切で根拠のあるものであると仮定しますが、スプリントにはあまりにも多くの作業を引き落としました（たとえば、ストーリーは実際には3ポイントの価値がありましたが、問題は15ストーリーポイントを引き下げたという事実にあります）あなただけをプルダウンする必要があります13）。見積もりを実行する能力に自信がない場合、これは潜在的に危険な仮定ですが、チームとプロセスに基づいて機能する可能性があります。

ただし、これは「製品バックログのレポートを台無しにする」と述べています。製品バックログはとにかく動的でなければならず、テクノロジー、システム、要件、および顧客についてより多くが理解されるにつれて、各ストーリーの順序と推定が変化します。通常、製品バックログからレポートされるのは、ユーザーストーリーの数とストーリーポイントの合計数です。これらは、優先順位が変更され、新しい要件が追加され、無効な要件が削除され、より多くの情報が学習されると、変更されることが予想されます。

これについて考えすぎると、実際よりも複雑に見えるようになります...実際には非常に単純です：

オプションC

不完全なストーリーは、ポイントが変更されることなく、製品のバックログに戻ります。次のスプリントと何ができるかを計画するとき、議論には多くの作業がすでに完了しているという事実を含める必要があります。チームがスプリントに合わせることができると判断した場合、元のポイント数で入ります。そうでない場合、バックログに残ります。できた ポイントは、ストーリーが完了したスプリントに付与されます。

役立つ場合は、ユーザーストーリーごとに個別の「作業残数」メトリックを追跡できます。これにより、スプリントの終わりまでにストーリーが完了しなかった場合、推定作業残数をストーリーに記録して、後続のスプリントに含めることを計画しています。ただし、その場合でも、元のストーリーのポイント値を変更しないでください。

レポートツールでオプションAを正確に処理できない場合は、メトリックを使用する見込みがない限り、オプションBを使用します。

場合によっては、オプションBを実行し、閉じようとしている古いタスクのスコープを狭めて、残っているスコープの新しいタスクのみを作成することにより、クローズしたことの意味を歪めないことができます。これにより、履歴が意味的に意味を持ち、通常、タスクをさらに細分化することを検討すべき場所を示します。場合によってはこれが不可能または論理的でなく、単純にそのレベルのタスクが発生するか、そのレベルの問題に直面することがあります。

編集： これは（私がOPが想定していたように）ほぼ完全な作業が優先順位でノックダウンされておらず、前の努力で見返りを得ることが作業を続けるためにリスト内で十分高く維持されることを前提としています。一部の店舗ではこれを行っていないことは知っていますが、私が働いたほとんどの場所では、何かが劇的に変更されない限り、ほぼ完全な残りのタスクを完了するだけで十分に価値があると考えています。コンテキストの変更のペナルティは、多くの場合、順序を変更する価値がありません。

私たちが引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリントプランニングセッションでどのように正しく見積もることができますか？

主にチームの速度に関して最も重要なのは、平均速度であり、特定のスプリントの速度が上がったか下がったかではないためです。

ユーザーストーリーを定義する場合、受け入れ基準が必要です。受け入れ基準のいずれかが行われない場合、チームは単にポイントを獲得しません。ストーリーが完成（POによってコーディング、テスト、および承認）された場合、チームはすべてのポイントを獲得します。

これは、チームが特定のスプリントの速度ではなく、平均速度に焦点を合わせている場合に有効です。

彼の本のM.コーンのように、私はオールオアナッシングのシナリオを好む傾向があります。結局のところ、8ポイントのストーリーのうち5ポイントを完了したのか、たぶん6または7だけが別の推測ゲームになってしまうのかを推定しようとすると...道を推定します。最も単純な方法を使用し、実際に完了した後にすべてのポイントを取得することをお勧めします。

M.コーンの本¹からの引用¹（私の強調）：

私は一般的に、速度を数えることに対するオールオアナッシングの姿勢に賛成です：ストーリーが完成（コード化、テスト、製品所有者による承認）された場合、チームはすべてのポイントを獲得しますが、ストーリー上の何かがなければ彼らは何も稼いでいない。反復の終わりに、これは評価するのが最も簡単なケースです。すべてが完了したら、すべてのポイントを獲得します。何か不足している場合、彼らはポイントを獲得しません。チームが次の反復でストーリーの残りの部分を引き受ける可能性が高い場合、これはうまく機能します。最初のイテレーションの速度は、ストーリーを部分的に完了することについて信用を得られなかったため、予想よりも少し遅くなります。ただし、2回目の反復では、反復の開始前に何らかの作業が完了していても、すべてのポイントを取得するため、速度は予想よりも高くなります。これは、特定の反復で速度が跳ね上がるか下がるかではなく、チームの経時的な平均速度に最も関心があることを誰もが覚えている限り、うまく機能します。

¹ アジャイルの推定と計画、部分的に完成したストーリーの再推定、p.66

私のチームは以前、いくつかの異議にもかかわらず、部分的なポイントを割り当てようとしましたが、うまく機能しなかったと思います。話が推定を取得することになっているので、これは特にそうである（私たちは姿を行く...もうそれをしない）チームとして、一人だけがそれに取り組んでいた場合、それがために、より困難になるだろうチームへ個人が実際にどれだけ完了したかを知る。アジャイルは、特定のスプリントがどのように「ナイス」に見えるかよりも、チームの平均速度に関心があります。

そうは言っても、著者は、チームが次の反復で残りの作業に取り組む可能性が低い場合、部分的なポイントの割り当てを検討できると述べています。この場合、チームは残っている作業を見積もって、必要と思われるサイズで新しいユーザーストーリーに分解します。著者が言及したように²：

組み合わせた推定値は、元の推定値と等しくする必要はありません...

²同上、p.66

チームにとっての推奨事項は、この種の問題を回避するために、ストーリーを十分に小さなサイズに分割することです³：

ただし、不完全なストーリーにポイントを割り当てるための2つの最適なソリューションは、不完全なストーリーを持たないことと、部分的なクレジットが問題にならないほど十分に小さなストーリーを使用することです。

³同上、p.67

お役に立てれば。

私は、これに対する直接的な答えがないように思われることに驚いています。「オプションD、ダミー」のコーラスを期待していました！

明らかなことを見逃していないように思われるので、これは、各チームがどのように働きたいか、どのメトリックスが彼らにとって最も重要であるかに基づいて、各チームが自ら決定する必要がある決定の1つであると考えました。

実装したユーザーストーリーの正確な記録を保持することが不可欠であると判断しました。これらはテスト、サポートドキュメント、およびリリースノートの基盤であり、オプションBを除外しているためです。

次に、スプ​​リント計画を正確に実行できることが不可欠であると考えました-オプションCを除外します。

したがって、オプションAが適切であると結論付けました。後続のスプリントで適切に計画できるように、スプリントで部分的に完了するストーリーのストーリーポイントを再評価します。製品のバックログは、やがて実装したストーリーポイントの量をわずかに下回ってしまいますが、これは他のオプションよりも問題が少なくなり、記録保持とレポートを変更することで解決できる可能性があります。

大文字化の目的でスプリントの反復に費やした時間（ユーザーストーリーに関連するタスクに費やした時間）を追跡し、POの目標が次のスプリント中にトラックを続けることである場合は、先のとがったユーザーストーリーを移動します。同じことを指します。

POの目標が他の何かをその場所に移動することである場合、未完成のストーリーをバックログに入れ、彼らが望むことを何でもします。私が推奨するのは、ポイントの元の推定値を残すことです。なぜなら、すべてのスプリントを噛むことができる以上に噛む習慣がある場合、スプリントのストーリーポイントを完全に完了せずに「完了」するからです。テスト済みアイテム。

スプリントに何かを残したい、指摘した、または出荷しなければならなかった場合、元のストーリー内のスライスポイントを決定し、それを完了ポイントに到達させ、その小さなピースをコミットするだろうと思いますあなたの反復のために。次に、残りの部分を再度ポイントして、バックログにドロップします。チームと話をスライスに分割することに同意したので、それは再見積もりの​​機会になります。

最初に尋ねる質問は、ストーリーポイントとはどういう意味ですか？ストーリーポイントを「作業エンジニアリングがどれだけ行われるか」と定義すると、どんな答えでも実行できます。ただし、ストーリーポイントを「ビジネスに提供される価値」と定義する場合、ストーリーが100％完了し、受け入れられ、100％提供されるまでクレジットを与えないことが重要になります。完了した内容に基づいてスプリントの後にストーリーポイントを変更すると、実際の問題が隠されるだけです。 ）ストーリーを完了するためのタスクや依存関係について十分に深く理解していない、e）ストーリーをテストする努力を過小評価している、f）ストーリーポイントが多すぎる、またはg）...理由をここに挿入する...

アジャイルの目標は、予測可能でありながら柔軟であることです。私の意見では、一貫性を保つための最善の方法は、元のストーリーの推定値を変更せずに、何がうまくいかなかったかを把握することです。