「ほぼ完成した」タスクまたはストーリーは、次のスプリントで過負荷の計画を正当化しますか？

問題のケース：

スプリントはほぼ終了し、私のスクラムチームの1つはいくつかのタスクを完了しませんでした。（この理由は、この質問では必須ではないので、それに応じて対処します。）それらの1つは、かなり多くのストーリーポイントを持つ古典的な「90％完了」のケースであり、次のスプリントの一部になります。こちらの質問です。

バックロググルーミングと次のスプリントのためのいくつかの予備的な見積もりを行い、この未完成のタスクを処理する方法について説明しました。このスプリントの速度にはカウントされないことに私たちは皆同意していますが、真の複雑さと実行された総作業を次のようにしたいので、5つのストーリーポイントではなく1でほぼ完全なケースを再推定しないでください。まだ見えています。そして推定を振り返ってみると正しかった。-私たちは（スケーリングされた）アジャイルに移行しているだけであり、一部の管理レベルでは、提供された製品よりも多くの点で生産性を維持していることを「確認」する必要があります。

明らかに、このスプリントの速度は低下しますが、転送された「既に完了した」パーツは、次のスプリントで再び上昇するはずです。

これまでのところ、全員が同意しています。

しかし、私たちのチームはかなり小さいので、4ポイントは大きなかたまりです。このタスクのみで適切なドキュメンテーションがあれば、意識的に4つのポイントの過負荷を計画できると提案しました。

それは実現可能なアプローチですか、それとも私は

• まだ予想していない問題に遭遇する
• ほんの数か月前にアジャイルに移行したチームに悪い例を示しますか？

スプリントの最後にストーリーが完了しない場合、ストーリーのポイントはそのスプリントの速度にカウントされず、ストーリーはバックログに戻ります。

次のスプリントの計画中にストーリーが終了するように選択されている場合は、残りの作業をすばやく再推定できます。この見積もりは、計画セッション中にのみ使用してください。実際に非常に少ない作業で完了する必要のある多数のポイントを持つストーリーがスプリントに不足していないことを確認してください。
ボード（および新しいスプリントの速度）では、持ち越されたストーリーの元の見積もりを使用する必要があります。

このように持ち越されたストーリーは、速度がスプリントごとに異なる可能性がある1つの理由であり、スプリントを計画するときは、平均を使用してチームの容量を計算する必要があります。

完了していないストーリーが次のスプリントで取得されない場合、再度取得されるときに完全なポイント値を計画することをお勧めします。これは、速度を上げるのにも時間がかかるためです。再び、チームが作業を停止したときの状態でした。

速度を実際よりも良く見せようとしないでください。今後は、タスクが完了しなかったことを認め、スプリントで実行できることを過大評価して失敗したことを認めます。しかし、それは人生であり、学ぶ機会でもあります。

したがって、不完全なタスクの場合は0ポイントです。

新しいスプリントについては、ストーリーポイントでタスクを完了するために必要な作業を見積もり、それを通常のタスクとして数えます。

あなたはあなたの速度が低すぎるように見えることを心配しています、あなたはあなたの速度が人為的に高すぎることを心配するべきです。

あなたが実際に達成できるよりも速い速度を持っていると、何度も何度も失敗するようになります。

私たちのチームでは、状況に応じて、いくつかの方法でキャリーオーバーストーリーを処理します。

• スプリントがほぼ終了し、すべての計画がすでに完了している場合（他のすべてのスプリントで発生）、バックログの次のストーリーから開始します（ただし、スプリントリリースにコミットしないでください）。これらは次のスプリントに自動的に含まれ、レポート目的ですべてのストーリーポイントが次のスプリントに移動します。

• ストーリーの一部が完全に完成し、それ自体にビジネス価値がある場合、通常、元のストーリーのスコープと見積もりの​​両方を再調整し、残りの部分はバックログに戻ります。

• ストーリーの最初の見積もりがずれていた場合（大規模で複雑なストーリーの場合に発生することがあります）、私たちはそれから学ぼうとします:)。現在のスプリントにストーリーポイントはありません。次のスプリント計画でストーリー全体を再推定してください。

一部のストーリーが前のスプリントから引き継がれる場合、スプリント計画では、空のスプリントバックログから開始しません。チームは、その上でどれだけの追加作業を実行できるかを決定します。例：通常のチームキャパシティ100 SP /スプリント、20ポイントはすでに進行中、チームは90個の新しいSPを取得することを決定したため、スプリントの開始時にスプリントに110個のSPが存在します。

このアプローチの主な欠点は、ベロシティレポートが、一部のマネージャが望むほどには良くないことです。しかし、長期的にはすべてが均等になり、このようにして、解放可能な可能性のあるすべてのものができるだけ早く配信され、チームは彼らの作業に対するクレジットを取得します。

背景：元々このチームはスプリントの期限に非常に厳密なアプローチをとっていたため、（2週間のスプリントの）最初の週に完了するよりも大きなストーリーを取り上げることを拒否し、小さくて安全なものを使用しましたスプリントの残りの部分のために働きます。これにより、スプリントの最後に空のスプリントバックログができましたが、「次に何に取り組むべきか」という質問に影響を与えすぎました。

これは簡単な答えの質問ではありません。何をすべきかについては多くの意見がありますが、まずは、満たす必要のあるさまざまなニーズを特定し、それらに基づいた解決策を考え出すことをお勧めします。例：

1. チームは、彼らがどのように機能しているかを理解し、改善の機会を特定する必要があります。ストーリーポイントを変更すると、対処する必要がある問題がマスクされることがあります。
2. プロダクトオーナーは、フィーチャー（多くの場合、フィーチャーレベルで集約される）またはリリース（SAFe-speakでは「PI」とも呼ばれます）に対して推定されたストーリーポイントの数を知ることができるように「必要」であり、 MVPまたはMMFの提供に向けた進捗状況を示す機能レベル（またはPI）。ストーリーポイントを変更すると、数値が歪んで混乱する可能性があります。

決定を導くのに役立つ「ガードレール」がいくつかあります。

• 作業は完了したかどうか。不完全な作業は、完了したスプリントにはカウントされません。
• 不完全なストーリーは優先順位を付け直す必要があります（次のスプリントに持ち越されることは「与えられた」ものではなく、バックログに戻ったり、放棄されたりする場合があります）。

そうは言っても、多くのチームがこれをさまざまな方法で処理するのを見てきました。

1. 不完全なストーリーがまだ有効でPOによって承認されている場合、ストーリー全体が次のスプリントに持ち越されます。これらのチームが頻繁に行うことは、これらのストーリーにタグ付けして、彼らが表す「残存作業」のポイントをいくつ見積もるかを見積もることです。つまり、13ポイントのストーリーで、残りが1ポイントしかない場合は、12を差し引いて計算を調整します。これにより、チームが能力を把握できるようにしながら、提案されたように元の推定値を履歴目的で残します。この場合、はい、速度ベースの容量「しきい値」より「多くのポイント」がある可能性があります。ただし、速度はわずかに変化する可能性があり、石で書かれていません。
2. チームがストーリーを分割し（たとえば、ラリーはこのための非常に優れた機能を備えています）、古いスプリントに「留まる」ストーリーの一部にいくつかのポイントを適用し、次に進む部分にポイントを適用します。このアプローチは便利ですが、「DoneはDONEを意味する」という原則に違反し、見積もりが不十分で作業が引き継がれる可能性があることを隠し、学習および改善の機会が失われる可能性があります。（これらの理由から、これは私の推奨ではありません）
   3. 私が見た最悪の解決策は、彼らが古いストーリーをDONEとマークしただけで、ポイントを下げたかもしれないし、そうでないかもしれないということでした。これは、標準であるIMHOによる醜い解決策です。

私が注目するのはこれです。「そのうちの1つは、かなりの数のストーリーポイントを持つ古典的な「90％完了」のケースです」-ここでの鍵は大きなストーリーです！投資を忘れないでください：ストーリーは小さくなければなりません。チームは、ストーリーを分割する（推奨）か、それらに群がるかを検討する必要があります。しかし、群がっていても、常に大きいほどリスクが高くなります。