4
「ほぼ完成した」タスクまたはストーリーは、次のスプリントで過負荷の計画を正当化しますか?
問題のケース: スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。(この理由は、この質問では必須ではないので、それに応じて対処します。)それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90%完了」のケースであり、次のスプリントの一部になります。こちらの質問です。 バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、真の複雑さと実行された総作業を次のようにしたいので、5つのストーリーポイントではなく1でほぼ完全なケースを再推定しないでください。まだ見えています。そして推定を振り返ってみると正しかった。-私たちは(スケーリングされた)アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。 明らかに、このスプリントの速度は低下しますが、転送された「既に完了した」パーツは、次のスプリントで再び上昇するはずです。 これまでのところ、全員が同意しています。 しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。このタスクのみで適切なドキュメンテーションがあれば、意識的に4つのポイントの過負荷を計画できると提案しました。 それは実現可能なアプローチですか、それとも私は まだ予想していない問題に遭遇する ほんの数か月前にアジャイルに移行したチームに悪い例を示しますか?