スプリント中に、予想外ではあるが、完了するには絶対に必要なタスクを完了する必要があることがわかりました。
これらをベストプラクティスとしてどのように処理しますか? このタスクをスプリント バックログに作成し、完了した時間をそこに入れる必要がありますか? それとも、最初に取り組んでいたタスクにこれらの余分な時間を追加する必要がありますか?
予期しないタスクは常にそこにあります。
開発者として、今後のスタンドアップ ミーティング (デイリー スクラム) で取り上げてください。スクラム ボードで見えるようにします。製品所有者/利害関係者がこのアドホックな要件を知っていることを確認してください。このような優先度の高い緊急のタスクに対応するために、優先度の低いユーザー ストーリーのコミットを解除するようにプロダクト オーナーに依頼してください。
これにより、チームの一貫した速度が得られます。このようなアドホック タスクはプロダクト オーナーに知られるため、スプリントの終了時に競合が発生することはありません。同等の複雑さを持つタスクはデコミットされるため、開発者が過負荷になったりプレッシャーをかけられたりすることはありません。
スプリント セッション中にストーリー用に作成されたタスクは始まりにすぎません。新しいタスクは、多くの場合、ストーリーの実現の一部として識別されます。通常、3 時間を超える場合は追加することをお勧めします。スクラム チームでは通常、完了した時間を追跡しませんが、残りの労力を費やしています。これは、スプリントの進捗状況を追跡するために使用するスプリント バーンダウン レポートを更新するので便利です。それが小さなタスクであり、残りの作業を別のタスクの一部として追加することが理にかなっている場合は、それも機能します。タスクを 2 日未満にすることをお勧めします。タスクが 2 日以上残っている場合は、それをより小さなステップに分解する方法を見つける必要があります。
Martin Rajotte - Incycle Software のスクラム コーチ兼 TFS エキスパート
予想外の仕事は必ずあります。不確実性のコーンはその事実において非常に明確であり、スクラムはこれを認めています。スプリント計画は、何を達成するかを決定し、開始する計画であると説明されています。
チームは ATDD などの別のメカニズムを使用して進捗状況を監視する可能性があるため、スクラムはタスクと時間の期待さえも排除しました。
つまり、短い答えです。チームにとって正しいと思われることを行います。ポイントは、自分のプロセスを発見することです。
まず、スプリントを完了するためにやらなければならないことがある場合は、それを実行し、必ず記録してください。
つまり、ストーリーを完了するために必要な新しいタスクを発見した場合は、それをストーリーに追加し、増加した残りのタスク (または時間) をバーンダウンチャートに記録し、計画外の作業としてマークします。
これがあなたが現在取り組んでいるストーリーとは関係のないタスクである場合は、(本当にそうしなければならないと仮定して) それを実行し、記録し、(計画外) とマークする必要があります。理由 (誰が、なぜ) を説明するストーリーを追加することを検討する必要があります。
重要なことは、ふりかえり中に計画外の作業を分析することです。計画に多くの労力を費やし、スプリントの安定性の重要性を伝えることで、これらの発生を最小限に抑えるよう努める必要があります (場合によっては)。
いずれにせよ、「私たちはアジャイル/スクラムを行っているため、このスプリントでは実行できない」という定説に反対することをお勧めします。本当に機敏になり、検査し、学び、適応します。