実行時間が長すぎるスプリント計画に対処するにはどうすればよいですか？
1週間のスプリントのスプリント計画に5時間以上かかりました。それは多すぎるようです。
チームメンバーのほとんどはシニアではないので、スプリント計画で詳細に話し合います。そうしないと、実装中にミスが発生し、スプリント中に再設計されます。
これにどのように対処しますか？
計画中に、1週間のスプリントあたりわずか2時間に収まるように、どれくらいの詳細を話し合う必要がありますか？
そうです-1週間のSprint Planningで5時間Sprintは長い時間のように思えます。スクラムガイドでは、スプリント計画を1か月間8時間にタイムボックス化し、「スプリントが短いほど、イベントは通常短い」と述べています。比率を考慮すると、適切な目標は、1時間のスプリントに対して2時間のスプリント計画である可能性がありますが、固定のタイムボックスはありません。
では、長いスプリント計画にどのように取り組むことができますか？
私はスクラムマスターとして、次の手順を実行します。
最初に、プロダクトオーナーと協力して、プロダクトバックログが適切に注文されていることを確認します。スクラムチームが適切な作業の定義、改善、準備に力を注ぐことができるように、最も重要な作業とその依存関係が製品バックログの最上部にあることを確認するには、効果的なバックログ調整とスプリント計画が不可欠です。
次に、チームがバックログの調整に十分な時間を費やしていることを確認します。スクラムガイドによると、改良作業は通常、開発チームの能力の10％以下しかかかりません。例として、標準の週に40時間働く4人の開発チームは、約16時間のバックログ調整を計画する必要があります。これは、個別に、小グループで、またはチームとして行うことができます。チームのために計画されたバックログ調整セッションを持ち、その後、調査、調査、または計画を実行するために脱出することが最も効果的であることがわかりました。
3番目に、スプリント計画ですべての詳細を正しく取得する必要がないことをチームが認識していることを確認してください。スプリント計画の目標は、スプリント目標を完了するための計画を作成することです。スプリントプランニングセッションで前もって大きなデザインをしようとしないでください。さまざまな作業がどのように適合するか、依存関係、目的を理解し、適切な人とスプリント計画セッション以外の時間を使用して、作業を行うために必要な設計、実装、およびテストを行います。
さらに多くのステップがこれらから外れる可能性がありますが、これは良い出発点になります。
私はあなたを聞く。使うには長すぎます！うまくいけば、あなたのチームはあなたの回顧でこれについて議論しています。さまざまな結果を組み合わせていくつかの実験を試みました。
全員が1つのチケットで高レベルの設計を行い、テーブルの周りを左右に渡して修正し、その後各チケットの計画のグループレビューを行います。誰もがこれを気に入ったわけではありませんが、それは私たちの後輩にそれを試させることを強いました。チームの一部の人は、他の人に考えさせて、指示に従うだけで非常に満足しています。したがって、プラス面では、私たちの実験は誰もが知識のギャップに直面することを余儀なくされ、ジュニアにとって成長の課題となりました。否定的な面では、誰もが現場に配置されることを好むわけではなく、必ずしも会議の時間を短縮するわけではありません。次！
ペアのデザインが試みられました。 2つまたは3つのグループは、チケットをタスクに分割します。チーム全体が結果の計画をレビューします。速度は大幅に向上しましたが、一部のミニポッドでは、1人が一緒に乗っているときに同じ問題が発生し、もう1人がデザインに取り組みました。
タスクの内訳をスキップします。ストーリーポイントが平均化されると判断したので、チーム全体をすべてに関与させるために時間を無駄にしていました。その結果、計画会議ははるかに短くなりましたが、チケットを開始するときにペアが自分たちのために行わなければならない設計作業でした。後輩がチケットに取り組んでいる場合、彼らがこのステップを乗り越えるには助けが必要になると期待してください。これを試してみると、スプリントに慣れるまで、受け入れられるストーリーの数が少なくなります。また、チームメイトが何かを知らないときに助けを求めることが「安全」であることを確認してください。
最終的には、チームの成熟度にかかっています。人々はお互いの能力と好みを理解し、チームメートが必要なときに入力を求めるという自信を持つ必要があります。あなたがそれらを持っていない場合は、最初にそれらを修正してください。次に、非効率的な会議の問題を解決することが容易になります。
@ Thomas-Owensから受け取った回答が気に入っていますが、もう1つ追加します。 アジャイル実装の一部としてペアプログラミングを行うことを検討しましたか？
ペアプログラミングは、（1）優れたコードの記述方法をジュニアプログラマーに教えるのに役立ちます。（2）ペアプログラミングでは、スプリントの計画で必ずしもすべての設計機能をレイアウトする必要はありません。ペアが連携することで、ペアのプログラミングの利点が追加され、これらの設計決定の一部を「自発的に」行うことができます。
ジュニアプログラマーがより速く学習できるように支援でき、Sprint Planningで対応しなかった設計項目が2人で決定されることがわかっている場合、費やす時間を削減できない理由はありません。今後のスプリント計画
私はスクラム愛好家ではなく、およそ1年の実務経験しかありません。したがって、次は塩の粒で読まれるべきです。
私はあなたが書いたものにいくつかの赤い旗を見ます：
5時間のスプリント計画
これは1週間のスプリントには長すぎる。
スプリント計画の目標は、AFAIRです。
- チームが現在の優先事項が何であるかを知ることができるようにし、
- 次のスプリントの戦闘計画を作成します。
これを効果的に行うには、双方がProduct Backlog itemsを理解する必要があります。
Product Backlog itemsを理解するには、バックログが適切な状態である必要があります。
具体的な計画段階では、Product Backlog itemsはSprint Backlog itemsに変換されます。
考えられる原因の1つは、これらのアイテムが十分に明確化/洗練されていないことです。
別の考えられる原因は、アイテムが複雑すぎて、解釈が多すぎる余地があることです。
スプリント計画で非常に詳細に話し合う
上記のように、項目がより具体的である場合、ディスカッションフェーズはより短くなります。
一方、スプリント計画では、すべての参加者に専門的な行動が求められます。これには、bikesheddingディスカッションの回避が含まれます。
多分物事は明確ですが、誰かがbikesheddingの議論を始めます。
詳細：実装の詳細に関する議論を避けます。すべてのアイデアは、ある時点でコードになってしまいますが、単純な配列がうまくいくか、リンクされたリストを使用する方が良いかは、スプリント計画の議論のポイントではありません。
チームのメンバーのほとんどはシニアではないので
スクラムでは、seniorとjuniorの間に違いはありません。どちらも単なる開発者です。これは良い出発点であり、給料ではなく、より良い議論に裏付けられた実行可能なソリューションに焦点を当てた議論を続けるのに役立ちます。
スプリント中の実装と再設計の間違い
要件収集に根本的な問題があり、非常にあいまいな製品バックログが続いているようです。
上記で述べたように、Product Backlogが適切な形である限り、要点を見逃すことはありません。
次のような状況は想像できません。
"ユーザーとして、少数の顧客に会いたい！"
"ああ、あなたは200万人の顧客のすべてを意味していませんでしたか？"
OTOH：この文脈でredesignはどういう意味ですか？開発者がslowパフォーマンスの高いアルゴリズムを選択した場合、次の明確な目標があります。より優れたパフォーマンスのアルゴリズムを選択することです。しかし、それは「再設計」ではなく、これは最適化です。
主な質問：
これに対処するには？
言及するのは簡単ですが、私はとにかくそれをします：あなたが人間を扱っていることを忘れないでください。
共通の概念を共有できるさまざまなマインドのグループを持つことは非常に困難です（たとえば Rashomon のように）。これに効果的に対処するには、可能な限り多くの冗長性を通信に使用します。誰もが何をすべきかを「知っているはず」だとしても、広範囲にわたる項目のコンテキストを説明します。誰もが特定のアイテムのトピックが何であるかを理解しているかどうか、質問します。
あなたがポーカーをプレーしている計画している場合は、理解が十分であるかどうか、つまりタスクの評価が低いかどうかを示す良い指標です。低いということは、複雑さが低いということは、理解しやすく、見逃すことが難しいということです。
反復の1つの副作用は、特定のタスクの数が増えることです（チームがその機能と隠れた複雑さを理解しているため）。次に、アイテムをいくつかの複雑さの低いアイテムに分解し、複雑さを軽減します。
1週間のスプリントごとに2時間に収まるように計画する場合、どのくらい詳細に話し合う必要がありますか？
サロモニック回答：可能な限り少なく、必要なだけ多く、それ以上ではありません。
tl; dr
誤解を避けるために、簡単な言語を選択します（役立つ場合は simple english または
ELI5を使用）。要件の収集を改善する
バックログを改善する
チームメンバーの個々の能力とチームとしての能力に対する自信を高める
バイクシェディングを避ける
個人の規律を改善する
議論するすべてのアイテムに固定タイムボックスを使用する
scrum masterの位置を強化して、効果的にモデレートします。