1週間のスプリントのスプリント計画に5時間以上かかりました。それは多すぎるようです。

ほとんどのチームメンバーはシニアではないため、スプリント計画で詳細を議論します。そうしないと、実装中にミスが発生し、スプリント中に再設計されます。

これにどう対処しますか？

1週間のスプリントあたりわずか2時間の長さに合わせるために、計画中にどの程度詳細に議論する必要がありますか？

そのとおりです-1週間のスプリントプランニングで5時間は長い時間のように思えます。スクラムガイドは、スプリント計画を1か月のスプリントで8時間に制限し、「短いスプリントの場合、イベントは通常短い」と述べています。比率を考慮すると、1週間のスプリントで2時間のスプリントプランニングが適切な目標となる場合がありますが、固定のタイムボックスはありません。

それでは、どのように長いスプリントプランニングに対処できますか？

スクラムマスターとして、次の手順を実行します。

最初に、プロダクトバックログが適切に注文されていることを確認するためにプロダクトオーナーと協力します。スクラムチームが適切な作業の定義、改良、準備にエネルギーを集中できるように、最も重要な作業とその依存関係が製品バックログの先頭にあることを確認することが、効果的なバックログの改良とスプリントプランニングに不可欠です。

次に、チームがバックログの調整に十分な時間を費やしていることを確認します。スクラムガイドは、改善活動は通常、開発チームの能力の10％を超えないことを示しています。例として、標準の週40時間で働く4人の開発チームは、約16時間のバックログ調整を計画する必要があります。これは、個別に、小さなグループで、またはチームとして行うことができます。私は、チームのために計画されたBacklog Refinementセッションを持ち、その後調査や調査、計画を行うためにブレークアウトすることが最もうまくいく傾向があることを発見しました。

第三に、チームがスプリントプランニングのすべての詳細を正しく取得する必要がないことを認識していることを確認します。スプリントプランニングの目標は、スプリント目標を完了するための計画を作成することです。スプリントプランニングセッションでは、前もって大きなデザインをしようとしないでください。さまざまな作業がどのように適合するか、依存関係、および目標を理解し、作業を提供するために必要な設計、実装、およびテストを行う適切な人とスプリントプランニングセッション以外の時間を使用します。

より多くのステップがこれらから脱落する可能性がありますが、これは良い出発点です。

私はあなたを聞く。それは費やすには長すぎます！できれば、あなたのチームがこれを回顧展で議論していることを願っています。いくつかの実験を試みましたが、結果はさまざまです。

1. 誰もが単一のチケットで高レベルの設計を行い、それをテーブルの周りで左右に渡して修正し、各チケットの計画をグループでレビューします。誰もがこれを気に入ったわけではありませんが、私たちの後輩に試してみることを強いました。チームの一部の個人は、他の人に考えさせ、指示に従うだけで非常に満足しています。そのため、プラスの側面として、私たちの実験は全員に知識のギャップに立ち向かうことを余儀なくさせ、後輩に成長への挑戦を提供しました。マイナス面としては、全員がその場に配置されることを好むわけではなく、必ずしも会議の時間を短縮するわけではありません。次！

2. ペア設計が試みられました。2つまたは3つのグループは、チケットをタスクに分解します。チーム全体が結果の計画をレビューします。それははるかに速くなりましたが、一部のミニポッドは一人が一緒に乗って、他の人がデザインの作業をするという同じ問題を抱えていました。

3. タスクの内訳をスキップします。ストーリーポイントを平均化することにしました。そのため、チーム全体をあらゆることに関与させるために時間を浪費していました。その結果、計画会議はずっと短くなりましたが、設計作業は、チケットを開始したときにペアが自分たちでやらなければならないことでした。ジュニアがチケットを処理している場合、このステップを通過するために彼らが助けを必要とすることを期待してください。これを試してみると、慣れるまでスプリントで受け入れられるストーリーが少なくなります。また、チームメイトが何か知らないときに助けを求めることが「安全」であることを確認してください。

最終的には、チームの成熟度に依存します。人々はお互いの能力と好みを理解し、チームメイトが必要なときにインプットを求めるという自信を持っている必要があります。持っていない場合は、まず修正してください。その後、非効率的な会議の問題を解決するのが簡単になります。

@ Thomas-Owensから受け取った回答が気に入っていますが、もう1つ項目を追加します。アジャイル実装の一部としてペアプログラミングを行うことを検討しましたか？

ペアプログラミングは、（1）優れたコードの記述方法をジュニアプログラマーに教えること、および（2）ペアプログラミングで、スプリントプランニングですべての設計機能を常に用意する必要がない場合に役立ちます。ペアが連携することで、ペアプログラミングの利点が追加され、これらの設計決定の一部を「自然に」行うことができます。

ジュニアプログラマーの学習をより速くすることができ、スプリントプランニングで対処しなかったデザインアイテムが2人で決定されることを知っている場合、あなたが過ごす時間を削減できない理由はありません。今後のスプリント計画

私はスクラム愛好家ではなく、実務経験は約1年です。そのため、以下は一粒の塩で読む必要があります。

あなたが書いたものにいくつかの赤い旗が見えます：

5時間のスプリント計画

これは1週間のスプリントには長すぎます。

スプリント計画の目標は

• チームが現在の優先事項を把握できるようにし、
• 今後のスプリントのための戦闘計画を開発する。

これを効果的に行うには、各側がを理解する必要がありProduct Backlog itemsます。

Product Backlog itemsバックログを理解するには、バックログが適切な状態にある必要があります。

具体的な計画段階では、Product Backlog itemsはに変換されSprint Backlog itemsます。

考えられる原因の1つは、これらの項目が十分に明確化/洗練されていないことです。

別の考えられる原因は、アイテムが非常に複雑であり、解釈しすぎる余地があることです。

スプリント計画の詳細について話し合う

上記のように、項目がより具体的である場合、ディスカッションフェーズは短くなります。

一方、スプリントプランニングでは、すべての参加者に専門的な行動が期待されます。これには、bikesheddingの議論の回避が含まれます。

たぶん物事は明らかですが、だれかが自転車を流す議論を始めます。

詳細：実装の詳細に関する議論を避けます。すべてのアイデアはある時点でコードになりますが、単純な配列がトリックを実行するか、リンクリストを使用する方が良いかどうかを議論するスプリント計画のポイントではありません。

ほとんどのチームメンバーはシニアではないため

スクラムでは、シニアとジュニアの区別はありません。どちらも単なる開発者です。そして、これは良い出発点であり、給料ではなく、より良い議論に裏打ちされた実行可能なソリューションに焦点を合わせ続けるのに役立ちます。

スプリント中の実装と再設計の間違い

要件の収集には根本的な問題があり、非常に曖昧な製品バックログが続くようです。

上で言ったように：Product Backlogが良い形である限り、ポイントを見逃すのは難しいでしょう。

次のような状況は想像できません。

»ユーザーとして、少数の顧客に会いたい！«

»ああ、あなたは私たちの200万人の顧客のすべてを意味しなかったのですか？«

大藤：この文脈での再設計とはどういう意味ですか？開発者がパフォーマンスの遅いアルゴリズムを選択した場合、明確な次の目標があります。パフォーマンスの良いものを選択してください。しかし、それは「再設計」ではなく、これは最適化です。

主な質問：

これに対処するには？

言及するのは簡単ですが、私はとにかくそれをします：あなたが人間を扱っていることを忘れないでください。

（羅生門のような）共通の概念を共有できるさまざまな心のグループを持つことは非常に困難です。これに効果的に対処するために、コミュニケーションで可能な限り冗長性を使用してください。誰もが与えられたアイテムのトピックが何であるかを知るかどうか、質問してください。

プランニングポーカーをプレイしている場合、理解が十分であるかどうかの良い指標は、タスクの評価が低いことです。低は、複雑さが低いことを理解しやすく、見逃しにくいことを意味します。

反復の副作用の1つは、特定のタスクの数が増えることです（チームがその能力と隠された複雑さを理解しているため）。次に、アイテムを複雑さの低い複数のより複雑でないアイテムに分割する機会があります。

1週間のスプリントあたり2時間の長さに合わせるために、計画中にどの程度詳細に話し合う必要がありますか

サロモニックの答え：できるだけ少なく必要なだけですが、それ以上ではありません。

tl; dr

• 誤解を避けるために、簡単な言語を選択してください（役立つ場合は、簡単な英語を使用するか、ELI5）

• 要件収集を改善する

• バックログの改善

• チームメンバーの個々の能力とチームとしての能力に対する自信を高めます

• 自転車の脱落を避ける

• 個人的な規律を改善する

• おそらく、議論するすべてのアイテムに固定タイムボックスを使用します

• scrum masterモデレートするための位置を効果的に強化します。

2週間のスプリントで合計3時間のグルーミングを行うことで、計画会議の時間を大幅に短縮することに成功しました。グルーミングを4つのセッションに分けます。毎週月曜日に30分グルーミング、水曜日に1時間グルーミングを行います。スプリントは月曜日に始まり、金曜日に終わります。結果として、会議のグルーミングから得られる情報が、計画への入力として役立ち、計画を短縮します。私たちの最高の記録は、スプリントの1つで30分の長さの計画会議でした。ほとんどの場合、1時間から1時間、30分以上かかりません。とにかくまだ時間枠がありますが、計画は非常に早く行われました。