スプリントアイテムの完了には予想よりも時間がかかります。私たちは何をすべきか？

スクラムのアイテムが予想よりも時間がかかる場合はどうすればよいですか？開発者が最初に考えたよりもずっと厳しいので、開発者が完了するのに苦労しているアイテムに気付いているので、私はこれを尋ねています。

そのような状況では

• スプリントのタイムラインを満たすために、アイテムをスプリントから製品カタログに戻しますか？
• より簡単なスプリントアイテムに移動し、タイムラインの最後まで問題のあるスプリントを残す
• スプリントレビューで、現在のスプリントで利害関係者にアイテムを完成できない理由を正当化する

今後、このような状況をどのように回避できますか？それは事前の計画の欠如によるものですか、それともスプリントアイテムを小さなアイテムに分解する努力をしなかったのですか？

「アイテム」とは、「タスク」を意味すると思います。

ソフトウェアの楽観的な計画は、ソフトウェア自体と同じくらい古いものです。スクラムの良いところは、すぐに直面し、それを可視化できることです。これが、チームの速度が将来の推定値ではなく過去のデータに基づいている理由です。

ストーリーを完了するには、予想よりもはるかに難しいタスクを完了する必要もあります。それらを延期する言い訳はありません。（これが、定義の完了が非常に重要である理由です）。もしそれがチームが物語に失敗しているということなら、それはひどく悪いことであり、あなたは次の回顧展で話し合うことができます。Velocityは低下し（より現実的になります）、チームはより良い見積もりを行うことを学習するか、予期しないタスクに対してより多くの安全マージンを残します。製品の所有者は、リリース計画についてより現実的な見解を得ることができます。

スクラムのアイテムが予想よりも時間がかかる場合はどうすればよいですか？

アイテムごとにストーリーを意味すると仮定すると、通常、スプリントの最後にそれを製品バックログに戻します（そして、おそらく次の反復のために計画します）。チームは現在の反復でゼロポイントを獲得します。

別の選択肢は、ストーリーが十分に大きい場合、垂直にスライスすることです。たとえば、ストーリー「製品カタログ検索」は、「カテゴリによる検索」と「全文検索」に分割できますが、「検索フォーム」と「検索結果」には分割できません。

今後、このような状況をどのように回避できますか？

これに対する簡単な直接的な答えはありません。スクラムでは、反復ごとにスプリントの回顧展を行います。通常、この種のことをチームと話し合います。多くの異なる可能性があります：

• チームまたは一部のチームメンバーは、悪い週を過ごしています
• チームは作業項目を水平方向にパイプライン処理します（バックエンド->フロントエンド-> QAなど）
• ストーリーは誤って大きすぎます
• チームは、ストーリーの完成に厳密に必要ではない余分な作業を追加することにより、ストーリーを「金メッキ」します。
• ストーリーは本質的に非常に大きく、長いスプリントが必要です（可能性は低い）
• チームはストーリーを不正確に（非一貫的に）見積もります
• プロジェクトには多くの技術的負債/腐敗したコードベースがあり、速度が低すぎます
• スプリントキャパシティを正確に測定および推定していない（またはまったくしていない）。

などなど

あなたはそれを終えないと言いますが、それは悪くない、それは単なるデータです。

「スプリントのタイムラインを満たす」は目標ではありません。あなたの目標は、ユーザーストーリーを完成させることです。タイムラインは、スプリントでどれだけの作業を行うことができるかを測定および学習するための単なるツールです。

スプリントで作業を終了できないことが確実な場合、1つの解決策は、優先リストの一番下に移動して、最初にスプリントの他のストーリーで作業することです。その後、残りの時間で作業を開始できます。次のスプリントに進む作業を再評価し、それを終了します。

振り返ってみると、何が間違っていたのかを話し合い、将来の見積もりを改善できるようにしてください。

タスクが予想よりも長くかかる場合、これを回顧で取り上げて議論する必要があります。初期の分析で見落とした部分はありましたか？これは、チームによって既に頻繁に行われていないことでしたか？何かが最初に見積もられたよりも長くかかる可能性のある理由はたくさんあります。

チームは、できる限り最善のタスクを実行するように努め、その後、レトロスペクティブでこれに関する戦略を議論する必要があります。チームがスクラムの使用にかなり慣れていない場合は、チームの初期速度の計算の一部である可能性があります。一部のチームは20ポイントを行うことができると考えるかもしれませんし、一部のチームは60ポイントを行うかもしれません。そのポイントは、各スプリントで同じ数のポイントをどれだけ一貫して行うことができるかです。

これは将来、チームがまだ行っていない新しいタスクを持っているときはいつでも、見積もりを作成するための多少の時間がかかる前に発生します。これは、それほど驚くべきことではない学習プロセスの一部です。

タスクが予想よりも長くかかるようになると、会社で通常行うことは、タスクを小さなタスクに分割することです。

そうすれば、開発者が遅すぎることを非難することはできませんが、タスクが誤って設計されたことも認識しています。

別のことは、開発チームの別のメンバーにタスクを割り当てて、後期開発者が穴に穴を掘るのを避けることです。タスクが本当に重要な場合、XPが解決策になる可能性があります。