スプリントアイテムの完了には、予想よりも時間がかかります。私たちは何をすべき？
スクラムのアイテムが予想よりも時間がかかる場合はどうすればよいですか？私がこれを要求しているのは、当初考えたよりもはるかに難しいため、開発者が完了に苦労している項目に気付いているからです。
そのような状況では
- スプリントからアイテムを削除して製品カタログに戻し、スプリントのタイムラインに対応できるようにしますか？
- より簡単なスプリントアイテムに移動し、タイムラインの終わりまで問題のあるスプリントを残す
- 現在のスプリントで関係者にアイテムを完了できない理由をスプリントレビューで正当化しますか？
今後、このような事態をどのように回避できるでしょうか。それは事前の計画の欠如によるものですか、それともスプリントアイテムをより小さなアイテムに分解するための努力をしなかったのですか？
「アイテム」とは、「タスク」のことだと思います。
ソフトウェアの計画の楽観主義は、ソフトウェア自体と同じくらい古いものです。スクラムの良い点は、すぐに直面してそれを可視化できることです。これが、チームの速度が過去のデータに基づいており、将来の推定値に基づいていない理由です。
ストーリーを完成させるには、予想よりもはるかに困難な作業を完了する必要もあります。それらを延期する言い訳はありません。 （これが、定義の完了が非常に重要である理由です）。それがチームがストーリーに失敗していることを意味している場合、それはあまりにも悪いことです。速度は低下し（より現実的になります）、チームはより適切な見積もりを行うか、予期しないタスクに対してより多くの安全マージンを残すことを学習します。製品所有者は、彼のリリース計画についてより現実的な見解を得るでしょう。
スクラムのアイテムに予想よりも時間がかかる場合はどうすればよいですか？
アイテムとはストーリーを意味すると仮定して、スプリントの最後に、通常は製品のバックログに戻します（そして、おそらく次の反復のために計画します）。チームは、現在のイテレーションでゼロ点を獲得します。
別の方法として、ストーリーが十分に大きい場合は、スライスすることができますvertical。たとえば、「製品カタログ検索」というストーリーは、「カテゴリによる検索」と「全文検索」に分割できますが、「検索フォーム」と「検索結果」には分割できません。
今後、このような事態をどのように回避できるでしょうか。
これに対する簡単な直接的な答えはありません。スクラムでは、反復ごとにスプリントを振り返ります。通常、このようなことについてチームと話し合います。さまざまな可能性があります。
- チーム、または一部のチームメンバーが悪い週を過ごしました
- チームパイプラインで作業項目を水平方向にパイプライン処理します（例：バックエンド->フロントエンド-> QA）
- 誤ってストーリーが大きすぎる
- チームは、ストーリーの完成に必ずしも必要ではない追加の作業を追加することで、ストーリーを「ゴールドプレート」します。
- ストーリーは本質的に非常に大きく、より長いスプリントが必要です（そうではない）
- チームはストーリーを不正確に（矛盾して）推定します
- プロジェクトには多くの技術負債/腐敗したコードベースがあり、速度が低すぎます
- スプリント容量を正確に（またはまったく）測定および推定していません。
などなど.
あなたはそれを終えないと言うが、それは悪くない、それは単なるデータである。
「スプリントのタイムラインを満たす」は目標ではありません。あなたの目標はユーザーストーリーを完成させることです。タイムラインは、スプリントで実行できる作業量を測定および学習するための単なるツールです。
スプリントで作業を完了できないことが確実な場合、1つの解決策は、それを優先リストの一番下に移動し、最初にスプリントの他のストーリーで作業することです。その後、残りの時間で作業を開始できます。次のスプリントに入る作業を再推定して、それを終了します。
将来の予測を改善できるように、何が問題であったかを話し合うことを振り返って確認してください。
タスクが予想よりも長くかかる場合は、これを振り返って検討する必要があります。初期の分析で見逃された作品はありましたか？これは、チームがまだ頻繁に行っていないことでしたか？何かが最初に見積もられたよりも長くかかる可能性のある理由はたくさんあります。
チームは、タスクを可能な限り最善の形で実行するように努めてから、遡及的にこれについて将来の戦略について話し合う必要があります。チームがスクラムの使用にかなり慣れていない場合は、チームの初期速度を計算することの一部である可能性があります。一部のチームは20ポイントを達成できると考え、一部のチームは60ポイントを達成する可能性があります。ポイントは、各スプリントで同じ数のポイントをどのように一貫して実行できるかです。
これは、チームが新しいタスクを実行するときに、見積もりを行うための時間をとるのに時間がかかる前に、将来発生します。これは学習プロセスの一部であり、それほど驚くべきことではありません。
タスクが予想よりも長くかかり始めたときに私たちが会社で通常行うことは、タスクをより小さなタスクに分割することです。
これにより、開発者が遅すぎることに責任があるわけではありませんが、タスクが正しく設計されていないことも認めます。
もう1つのことは、開発チームの別のメンバーにタスクを割り当てて、後期開発者が穴を掘るのを防ぐことです。そして、タスクが本当に重要である場合、いくつかのXP=が解決策になる可能性があります。