スクラム-バックログを歪めずに、部分的に完成したユーザーストーリーを次のスプリントに引き継ぐ方法
私たちはスクラムを使用していますが、計画されたスプリントでユーザーストーリーを完成できないことがあります。真のスクラムスタイルでは、とにかくソフトウェアを出荷し、次のスプリント計画セッション中に次のスプリントにユーザーストーリーを含めることを検討します。引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリント計画セッションでそれを正しく見積もるにはどうすればよいですか？私たちは検討しました：
a）ストーリーポイントの数を調整して、ユーザーストーリーを完了するために残っている作業のみを反映します。残念ながら、これは製品バックログの報告を台無しにしてしまいます。
b）部分的に完成したユーザーストーリーを閉じ、新しいストーリーを上げて、残りの機能を実装します。ストーリーポイントは少なくなります。これは、そのスプリントで完了しなかったものを遡及的に確認する機能に影響し、少し時間がかかるようです。
c）aとbのどちらにも煩わされず、Sprint Planningで「ユーザーストーリーはXストーリーポイントかもしれませんが、95％完成しているので、納得できると確信しています」のように推測し続けます。
これに対する正直な答えがないように私は驚いています。 「オプションD、ダミー」の合唱を期待してました！
明らかな欠落がないように見えたので、これは、各チームがどのように働きたいか、どのメトリックが最も重要であるかに基づいて、各チームが自分で行う必要がある決定の1つであると考えました。
実装したユーザーストーリーの正確な記録を維持することが不可欠であると判断しました。これらは、テスト、サポートドキュメント、リリースノートの基礎となるため、オプションBは除外されます。
次に、スプリントの計画を正確に実行できることが不可欠であることを理解しました。これにより、オプションCが除外されます。
したがって、オプションAが適切であると結論付けました。後続のスプリントで適切に計画できるように、スプリントで部分的に完了したストーリーのストーリーポイントを再推定します。時間の経過とともに、製品のバックログは実装したストーリーポイントの量をわずかに下回りますが、これは他のどのオプションよりも問題が少なく、記録の保存とレポートを変更することで解決できる可能性があります。
私の現在のチームではc）を行います。
ベロシティは、チームがスプリントで実際に終了したものを説明する必要があります。提供されなかったものは顧客にとって価値がないので、ポイントは数えません。全部かゼロかです。
したがって、未完成のストーリー全体を次のスプリントにシフトし、すべてのストーリーポイントを次のスプリントの速度に追加します。速度は時間とともに均一になり、将来の速度の推定値を決定するための参照として、過去のいくつかのスプリントの平均を採用します。
オプションAは、一般的に推奨される一連のアクションです。前のスプリントのストーリーの完了に対してポイントを付与したり、ストーリーを製品のバックログに戻したりして、優先順位を再設定します。完成したユーザーストーリーと付加価値に基づいて、速度（およびその他のメトリック）を計算します。次のスプリントの計画を開始するときは、価値に基づいて最も優先度の高いストーリーを採用します（ビジネスの優先順位が変更された場合、未完成のストーリーが含まれる場合と含まれない場合があります）。ストーリーを見積もるときは、ストーリーの新しいポイント数を考慮に入れるときにすでに行われた作業を含めます。
もちろん、代替オプション（および私の好み）は、ストーリーポイントの元の推定数を使用することです。これは、私が過去に行ったことです。これは、見積もりが適切で根拠のあるものであると仮定していますが、スプリントに対してあまりにも多くの作業を引き下げました（たとえば、ストーリーは実際には3ポイントの価値がありましたが、問題は、15のストーリーポイントを引き下げたという事実にあります。 13）をプルダウンするだけで済みます。推定を実行する能力に自信がない場合、これは潜在的に危険な仮定ですが、チームとプロセスに基づいて機能する可能性があります。
しかし、これは「製品バックログの報告を台無しにする」と述べています。技術、システム、要件、顧客について理解が深まるにつれ、製品バックログは動的になり、各ストーリーの順序と見積もりは変化します。通常、製品バックログから報告されるのは、ユーザーストーリーの数とストーリーポイントの総数です。これらは、優先順位の変更、新しい要件の追加、無効な要件の削除、およびより多くの情報の学習に伴って変更されることが予想されます。
これについて考えすぎると、実際よりも複雑に見えます...実際には非常に単純です。
オプションC
不完全なストーリーは、ポイントが変更されることなく、製品のバックログに戻ります。次のスプリントと何ができるかを計画するときは、多くの作業がすでに完了しているという事実を議論に含める必要があります。チームがそれをスプリントに合わせることができると判断した場合は、元のポイント数で開始します。そうでない場合は、バックログに残ります。できました。ストーリーが完成したスプリントにポイントが付与されます。
それが役立つ場合は、ユーザーストーリーごとに個別の「残存作業時間」メトリックを追跡できます。これにより、スプリントの終わりまでにストーリーが完了しない場合、推定残存作業時間がストーリーに記録され、いつ考慮されるか後続のスプリントへの組み込みを計画しています。ただし、それでも、元のストーリーのポイント値を変更しないでください。
レポートツールでオプションAを正確に処理できない場合は、メトリックを使用する見込みがない場合を除き、オプションBを使用します。
場合によっては、オプションBを実行し、閉じようとしている古いタスクのスコープを狭めて、残っているスコープに対してのみ新しいタスクを作成することで、閉じた意味を歪めないようにすることができます。これにより、履歴が意味的に意味をなすようになり、通常、タスクをさらに分解することを検討する必要がある場所を示します。時々、これは不可能であるか論理的ではなく、あなたは単にそのような大きなタスクやそのレベルの問題にぶつかるタスクを持っているだけです。
編集：これは（ほぼOPが想定していたように）ほぼ完了した作業が優先的にノックダウンされておらず、前の努力の成果が得られても、リストの中で十分に高く維持されていることを前提としています。ワーキング。一部のショップではこれを行わないことは知っていますが、私が働いたほとんどの場所では、ほぼ完全な残りのタスクを完了することを検討して、何かが劇的に変化しない限り、単純に継続するのに十分価値があるようにします。多くの場合、コンテキストの変更によるペナルティは、順序を変更する価値がありません。
引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリント計画セッションでそれを正しく見積もるにはどうすればよいですか？
オプションAからCは良いとは思いません。主に、チームの速度に関して（私が思うに）最も重要なのは平均速度であり、特定のスプリントの速度が上昇したか下降したかではありません。
ユーザーストーリーを定義するときは、受け入れ基準が必要です。受け入れ基準に何かが行われていない場合、チームはポイントを獲得しません。ストーリーが完了した場合（つまり、コード化され、テストされ、POによって受け入れられた場合）、チームはすべてのポイントを取得します。
これは、チームが特定のスプリントの速度ではなく、平均速度に焦点を合わせている場合にうまく機能します。
M.コーンの本のように、私はオールオアナッシングシナリオを好む傾向があります。結局のところ、8ポイントのストーリーから5ポイントを完了したか、おそらく6または7だけを完了したかを推定しようとすると、もう1つの推測ゲームになってしまいます...そして、すでにイニシャルを取得していることを忘れないでください道を外します。最も単純な方法で行って、実際に完了した後ですべてのポイントを取得することをお勧めします。
M.コーンの本からの引用Qu（私の強調）：
私は通常、速度をカウントすることに対して全か無かのスタンスを支持しています。ストーリーが行われた場合（コード化され、テストされ、製品所有者によって受け入れられた場合）、チームはすべてのポイントを獲得しますが、ストーリーに何かがある場合行われません、彼らは何も稼ぎません。反復の最後に、これは評価するのが最も簡単なケースです。すべてが完了したら、すべてのポイントを取得します。不足しているものがある場合、ポイントは獲得できません。チームが次のイテレーションでストーリーの残りの部分を引き受ける可能性がある場合、これはうまく機能します。最初の反復での速度は、ストーリーを部分的に完了したことに対するクレジットがなかったため、予想よりも少し低くなっています。ただし、2回目の反復では、いくつかの作業が反復の開始前に完了していたとしても、すべてのポイントを取得するため、速度は予想よりも高くなります。 これは、特定の反復で速度が上昇したか下降したかではなく、時間の経過に伴うチームの平均速度に主に関心があることを誰もが覚えている限り、うまく機能します。
¹アジャイル推定と計画、部分的に完了したストーリーの再推定、p.66
私のチームは以前、一部の異議にもかかわらず、部分的なポイントを割り当てようとしましたが、それがまったくうまく機能しなかったと思います。 （私たちはもうそれをしません...図に行く）ストーリーはチームとして推定されるために特にそうです、それでもチームが個人をどれだけ知っているかは難しくなりますは実際に完了しました。アジャイルは、特定のスプリントがどのように「ナイス」に見えるかよりも、チームの平均速度に関心があります。
とはいえ、著者がdoesは、チームが次の反復で残りの作業に取り組む可能性が低い場合は、部分的なポイントの割り当てを検討できると述べています。この場合、チームは残っている作業を見積もり、必要なサイズで新しいユーザーストーリーに分解します。著者が言及しているように²：
結合された推定値は元の推定値と同じである必要はありません...
²同上、p.66
チームにとっては、この種の問題を回避するためにストーリーを十分に小さなサイズに分割することをお勧めします³：
ただし、不完全なストーリーにポイントを割り当てるための2つの最良の解決策は、不完全なストーリーがないことと、部分的なクレジットが問題にならないほど十分に小さいストーリーを使用することです。
³同上、p.67
お役に立てれば。
大文字化の目的でスプリントの反復に費やされた時間（ユーザーストーリーに関連するタスクに費やされた時間）を追跡し、POの目的が次のスプリント中にトラックを続けることである場合は、ポイントされたユーザーストーリーを移動し、同じを指します。
POの目的が別の場所に移動することである場合、未完成のストーリーをバックログに入れ、彼らが望むことは何でも行います。ポイントの最初の推定値を残すことは私の推奨です、あなたが噛むことができるよりも多くを噛む習慣があるなら、あなたはすべてのスプリントで、あなたは完全に行われていてきれいではなかったスプリントのストーリーポイントを「完了する」でしょう。テストされたアイテム。
スプリントに何かを残したい、指さした、または出荷する必要があった場合は、元のストーリー内のスライスポイントを決定し、それまでに完了ポイントに到達し、その小さなピースをコミットすると思います。あなたの反復のために。次にremainderが再度ポイントされ、バックログにドロップされます。ストーリーをスライスに分割することについてチームと合意したので、それは再推定の機会です。
最初に尋ねる質問は、ストーリーポイントの意味は何ですか。ストーリーポイントを「どのくらいの作業エンジニアリングが行われるか」と定義すると、どのような答えでもかまいません。ただし、ストーリーポイントを「ビジネスに提供される価値」と定義した場合、ストーリーが100％完成し、受け入れられ、100％提供されるまでクレジットを付与しないことが重要になります。完了した内容に基づいてスプリント後にストーリーポイントを変更しても、実際の問題が隠されるだけです。a）ストーリーが明確に理解されていなかった、b）ストーリーがあまりに大まかに定義されていなかった、c）ストーリーに測定可能な受け入れ基準がなかった、d ）ストーリーを完成させるためのタスクまたは依存関係を十分に理解していない、e）ストーリーをテストする努力を過小評価している、f）ストーリーポイントが多すぎる、またはg）...ここに理由を挿入...
アジャイルの目標は、予測可能でありながら柔軟であることです。私の意見では、一貫性を保つための最良の方法は、元のストーリーの見積もりを変更せずに何が問題だったかを理解することです。