スプリント計画会議はいつまで続くべきですか？

あなたの経験では、スプリントプランニングミーティング（スクラム）の期間はどれくらいですか？8時間？それとももっと短く（簡潔に）、スプリントの一部としてさらなる議論を計画すべきですか？私たちのスプリントは10日間です。

スクラムガイドによると：

スプリントプランニングミーティングは、1か月間のスプリントで8時間に制限されています。スプリントが短い場合、イベントはそれに比例して短くなります。たとえば、2週間のスプリントには4時間のスプリントプランニングミーティングがあります。

それは一般的に私のために動作します。

それが持続する必要がある限り、それ以上でもそれ以上でもありません。それ以外はアジャイルではありません。

2〜3人の開発者から成るチームがいて、1週間のスプリントを行っている場合、1時間を超えると生産性が低下する可能性があります。

15人のチームと2週間のスプリントを1日中見ている場合、それより少ないものは十分に詳細ではありません。

それをほとんど正しくするためには経験が必要であり、それが回顧の目的です。チームは長すぎるか短すぎるかを決定します。

それを完璧にしたり、いくつかの本が言っていることに固執することを心配しないで、何かを試して、それを洗練してください。

SCRUMは、反復でコードを洗練することと同じくらい、反復でプロセスを洗練することです。

プロセスを中心にビジネスを形成しないでください。このプロセスはあなたのビジネスをサポートします。あなた自身のためにプロセスを行っている瞬間、それはプロセスがxを取得する時です。そのためには、「正しい」方法はありません。会議は、会議で何かを達成している場合にのみ行ってください。動作する限り、30分または4時間かかります。いくつかの本/ブログ/コーチがあなたに伝えることを無視して、あなたに合ったことをしてください。

チームがスプリントで合理的に達成できると思うほど十分に選択できるように、必要な時間をかけてください。ただし、（前の）スプリント中に時間をかけてバックログを調整する必要があります：ストーリーの推定と調整。

スクラム入門書（PDF）から：

製品バックログの改良

あまり知られていないが価値のあるスクラムのガイドラインの1つは、各スプリントの5〜10パーセントをチームが製品バックログの改良（または「グルーミング」）専用にする必要があるというものです。これには、詳細な要件分析、大きなアイテムの小さなアイテムへの分割、新しいアイテムの推定、および既存のアイテムの再推定が含まれます。スクラムはこの作業がどのように行われるかについて沈黙していますが、頻繁に使用される技術はスプリントの終わり近くに焦点を当てたワークショップです。そのため、チームとプロダクトオーナーは中断することなくこの作業に専念できます。2週間のスプリントの場合、期間の5パーセントは、各スプリントに半日の製品バックログ調整ワークショップがあることを意味します。この絞り込みアクティビティは、現在のスプリント用に選択されたアイテム用ではありません。これは、将来のアイテム用であり、おそらく次の1つまたは2つのスプリントでのものです。プロダクトオーナーとスクラムチームが明確で、十分に分析され、慎重に見積もられたアイテムのセットから計画を開始するため、このプラクティスでは、スプリント計画が比較的簡単になります。この改善ワークショップが行われていない（またはうまく行われていない）兆候は、スプリントプランニングが重要な質問、発見、または混乱を伴い、不完全だと感じることです。その後、計画作業はしばしばスプリント自体に波及しますが、これは通常望ましくありません。

これにより、計画中に計画に集中できるようになり、1日もかからず、チームは集中力を失い、退屈し始めます。

スクラムでは、2週間のスプリントに取り組む場合、スプリント計画は4時間でタイムボックス化され、半日のイベントになります。比較的長い時間のための一つの理由は、開発チームがあることである必要があり、自信を持ってスプリントバックログに引き込まれているすべてのアイテムは、彼らが詳細を知っている必要がありますを意味し、配信できることに同意することができます。チームがスプリント計画の一環として、アイテムをさらに調査し、スプリントバックログに進む準備ができていることを確認するために、一定期間ミーティングスペースから離脱することは珍しいことではありません。（スプリント計画を会議ではなくイベントとして考えると役立ちます。）

「準備の定義」と、スプリント計画イベントでスプリントに入るすべてのバックログアイテムが実行可能で準備が整っていることを確認できる時間の長さを使用します。つまり、スプリント内で（完全に、「完了の定義」に従って）実行でき、チームが今すぐ実行できる十分な情報があります。
もちろん、スプリント計画中にすべてのアイテムに対してこれを行うことはおそらく非常に時間がかかるため、これを行いたくないことに注意してください。バックログアイテムを分類し、たとえばプランニングポーカーを使用してまだ推定されていないアイテムを推定できる、通常のバックロググルーミング（スプリント計画なし）を試してみてください。（これは、開発チームとの夕食会で、夕食時にチームの空室状況に余裕がある場合に効果的なアクティビティになります！）

優先順位の高いアイテムは、スプリント計画の直前に製品所有者によって製品バックログに追加されることがよくありますが、通常のバックログのグルーミングはスプリント計画イベントの前に行うことができ、通常は行う必要がありますが、常にこのような新しいアイテムがありますチームは、スプリントプランニングイベント中に詳細の計算と複雑さの推定に時間を費やす必要があるため、10日/ 2週間のスプリントで4時間に及ぶ可能性があります。

このイベントからより長い議論を行う必要がある場合は、スプリントバックログに「xを確立するためにそのような議論を行う」ためのバックログアイテムがある場合がありますが、スプリントアイテムを含めて何でもすることは避けてくださいそれらはスプリントに入る「準備ができた」バックログ項目ではないため、その議論の間に行われたニーズを決定します。

人々が言っ​​たように、プロセスがあなたのために効果的に機能していない場合、スクラムを実行する方法を変更したいかもしれない理由があります。ただし、スクラムは非常によく考え抜かれたテスト済みのフレームワークであるため、プロセスを変更する前にあなたの推論が正当であることを確認します。

Sprint Planning Meetingでは、チームは次の2つのセットを決定する必要があります。

A）このスプリント中にチームが開発するもの

B）開発方法

この会議は、スプリントの各週に最大2時間まで、会議の各部分（パートAとパートB）に均等に分割されたタイムボックスである必要があります。

したがって、4週間のスプリントの場合、この会議は8時間以内、パートAでは最大4時間、パートBでは最大4時間でなければなりません。

パートAの間に、開発チームは、このスプリント中にチームチームの速度を見積もる必要があります。また、最優先のユーザーストーリーを推定し、これらの（既に推定された）ユーザーストーリーを十分に選択して、チームの推定速度に合わせて完了する必要があります。

パートBでは、開発チームは、開発対象として既に選択されているより困難なユーザーストーリーを開発する方法について説明します。ほとんどの場合、開発チームは、選択したすべてのユーザーストーリーを開発する方法を議論する十分な時間がないため、最も困難なユーザーストーリーを選択する必要があります。

スプリントの間、開発チームはこの議論を完了するのに十分な時間を持っています。

スクラムガイドによると：

スクラムイベント

スクラムでは、規則性を作成し、スクラムで定義されていない会議の必要性を最小限に抑えるために、規定のイベントが使用されます。すべてのイベントはタイムボックス化されたイベントであるため、すべてのイベントの期間は最大です。スプリントが開始されると、その期間は固定され、短縮または延長することはできません。残りのイベントは、イベントの目的が達成されるたびに終了する場合があります。これにより、プロセスの無駄を許さずに適切な時間が費やされます。