スプリント計画の最後ではなく、開始時に速度を念頭に置いておくことをお勧めします。
Velocity は、開発チームへのガイドです。たとえば、ベロシティが 15 の場合、その合計数のストーリー ポイントをスプリントに使用することを検討します。ただし、スプリント計画の一環として、それらのストーリーをタスクに分解します。この時点で初めて、彼らは次のスプリントで何ができるかを明確に把握できます。10 ストーリー ポイントかもしれませんし、20 ストーリー ポイントかもしれません。速度はあくまでも目安です。
また、開発チームから何かを隠すことは本当に悪い考えだと付け加えてもいいですか。スクラムの柱の 1 つは透明性です。
また、スクラム ガイドの最新版では、「コミットメント」という言葉への言及がすべて削除されています。現在、より正確には「予測」という言葉を使用しています。
それが役立つことを願っています。
これは、チームのトラック履歴と過去数回のスプリントでのチームの速度によって異なります。したがって、彼らがしばらくの間平均7であった場合、10のストーリーを受け入れることは、チームを失敗させることになります。
マイナーな修正ですが、「コミットメント」という用語は、経営陣によって誤って解釈され、チームがコミットメントを満たさない場合は「死の行進」に苦しむため、使用しなくなりました。彼らはスプリント目標の95％を達成しましたが。代わりに、不確実性、複雑さ、予期しないイベントに基づいて成功を保証することはできないため、予測という言葉を使用します。
チームがそれらを達成できるように、ストーリーをより小さなストーリーに分割してみてください。ただし、各スプリントをより良くし、各スプリントを少し強く押すように促してください。したがって、回顧展では、「改善し、より多くのことを行うために何ができるか」と尋ね続けます。チームが感じていることを現実的にしてください。
あなたのスプリント計画において、チームは彼らが本当にそれを達成できると感じていますか？そうでない場合は、そのような大きなストーリーにどのように取り組むかを再考するか、それを分解して、付加価値のある増分を提供します。
チームから物事を隠さないでください。スクラムは、透明性、開放性、および健全な作業環境に関するものです。あなたが物事を隠し始めると、チームもあなたから物事を隠し始めます。
ベロシティは良い尺度であり、過去のパフォーマンス/ベロシティに基づいて、スプリント全体で予測できます。通常、スプリントでは速度の見積もりにバッファーが考慮されるため、不測の事態が考慮される場合があります。このバッファは、履歴データ、今後の PTO などに基づいています。
この質問は、製品ベースのチームとサービス ベースのチームの両方の観点から見ることができます。製品チームの場合、スプリントに入る要件は、サービス チームよりも柔軟な場合があります (柔軟性の低いクライアントを扱う場合があります)。
理想的には、チームはバックログ グルーミング自体でベロシティを念頭に置いています。これにより、スクラム チームはバックログから、予定どおりに完了することが期待されるストーリーを引き出すことができます。スプリント計画では、制作チームが機能要件をよりよく理解するために、これらのグルーミング/サイズ設定されたユーザー ストーリーのニュアンスについてさらに話し合います。
次のスプリントの新しいストーリー ポイントのベースラインとしてベロシティを維持できますが、これは必須ではなく、チームのコミットメントに影響します。各チームは自分自身に匹敵します。ベロシティを使用して新しいストーリー ポイントを比較し、自分自身を改善して配信をスピードアップすることができます。