私たちのスプリント計画会議は面白くないだけでなく、実に恐ろしいものです。

会議は退屈で退屈で、永遠にかかります（1日ですが、ずっと長く感じます）。
開発者はそれについて文句を言い、今後の計画を恐れます。

私たちのルーチンはかなり標準的です（優先順位によってスプリントバックログに挿入されるユーザーストーリー>>ストーリーはタスクに分解されます>>タスクは時間単位で見積もられます>>繰り返し）、何が間違っているのかわかりません。

どうすれば会議をもっと楽しくすることができますか？

...

詳細情報のリクエストへの応答として、さらに詳細を示します。

バックグラウンドアイテムがスプリントキックオフの前に挿入および優先順位付けされないのはなぜですか？

ユーザーストーリーは確かに優先されます。それらをタスクに分解するまで、どれだけ時間がかかるかわかりません！ここの（優れた）回答から、タスクをまったく推定すべきではなく、ユーザーストーリーのみを推定すべきであることがわかります。タスク（ストーリーではなく）を見積もる理由は、ストーリーの見積もりがひどく間違っているためです。しかし、それはまったく異なる質問の主題だと思います。

開発者が文句を言うのはなぜですか？

1. 会議は長いです。

2. 会議は単調です。ストーリーごと、タスクごと、苦労（はい、苦労）にかかる時間とその内容を推定します。

3. タスクを見積もると、ユーザーストーリーの推定が無意味に見えます。

4. 会議が長ければ長いほど、部屋に集中できなくなります。集中力の低い同僚ほど、会議に時間がかかります。再帰的なヘイトスパイラルが発生します。人々を集中させるために会議を2日間に分割することを検討しましたが、開発者はそれを聞きませんでした。計画の1日で十分です。これで2つになります。

私たちの問題の一部は、（より正確な推定を得るために）非常に小さな詳細になることです。しかし、おおよその見積もりをするときは、大したことはありません！

質問を要約するには：

• 私たちは何を間違っていますか？

• 一般的に会議をより楽しくするために、他にどのような方法がありますか？

見積もりを簡単にする

スプリント計画を打ち破ります。

あなたが必要な個々のタスクを推定するために？次の2つの方法でスプリント計画を行いました。

1. ストーリーはストーリーポイントで推定され、その後タスクは時間で推定されます
2. ストーリーはストーリーポイントで推定され、タスクは推定なしでその下に単純に分類されます

2つのうち、2番目のオプションを好みます。タスクを見積もらないことで、開発者が変更に対処する自由が増えます。タスクが意味をなさない場合（タスクが適用できない、または以前のスプリントで既に行われていることがわかった回数）、ペナルティなしで単純にそれを破棄するか、現在のタスクを何か新しいもの、おそらくそれを分割する。タスクの合計はストーリーポイントを表し、その逆も同様であるため、両方を見積もると本当に冗長になります。これにより、個々のタスクにかかる時間を知ること以外に、実際にどのような価値が得られますか？違いを生むのに十分な大きさのタスクサイズがある場合は、それらのタスクをより小さく、より均質なチャンクに分割することをお勧めします。

これにより、スプリント計画に費やす時間を削減できます。スプリントの計画中にストーリーが推定され、スプリントを開始すると、そのストーリーを構成する考えられるすべてのタスクを書き留めることができます。明らかに、タスクで対処する必要があることがわかっているストーリーを推定する際に出くわす点がある場合は、ストーリー情報に追加して、それをタスクとして配置できます。

理想的な単位で推定

ストーリーポイントは、理想的な労働時間や理想的な就業日などの理想的な単位にすることを意図しています。これらは、毎日完璧な日があり、中断や会議がなく、すべてが計画どおりに進んだことを考えると、X日でタスクを達成できることを意味します。今では誰もがこれが単に真実ではないことを知っていますが、統計に関する素晴らしいことはそうである必要がないことです。

これが意味することは、これらを理想的な日に推定してからしばらくすると、ストーリーを完成させるのに平均で推定25％の時間がかかることに気付くということです。理想的な就業日を4日と見積もっていたのに、5時間がかかったとしましょう。時間が経つにつれて、これを追跡し、理想的な日から実際の日への変換の大まかなアイデアを得ることができます。あなたの最初の本能は、過大評価によってこれを補償しようとすることであり、あなたはおそらく間違っているでしょう。ここでの主なことは、一貫性を保つことです。そうすれば、長期的な平均は変わりません。確かに、それは下にあり、時には上になりますが、あなたが推定するほど、あなたはより良いです。あなたがいることが判明した場合、まだ 適切な推定値を取得できません。おそらく、ストーリーを適切に推定するのに十分な知識がないことを意味します。

ストーリーについて話す

推定するとき、誰もが最初から最後まで、このストーリーを完成させるために何をする必要があるかについて大まかな考えを持っている必要があります。あなたはすべての詳細を知る必要はありませんが、あなた自身が物語を引き受けることができると思うのに十分です。あなたがそのレベルの自信を持っていないなら、おそらくそれを推定すべきではないでしょう。「このストーリーは大きすぎてほとんどの詳細を知ることができない」と言う場合、それはストーリーが大きすぎて、分解する必要があることを示しています。ストーリーは、少なくとも私の経験では、1人が必要に応じて単独で作業し、1、2週間で達成できるほど十分に小さいものでした。

これはまた、ある編集で、あなたの第二の点、解決するのに役立ちますあまりにも多くの推定を。ストーリーごとにすべてのタスクを見積もるのではなく、単にストーリー全体を見積もるだけで、多くの見積りを削除できます。ミーティングの単調さを軽減するために、ポーカーを計画することをお勧めします。ポーカーについては、上記の詳細をご覧ください。

計画をより魅力的にする

Planning Pokerを使用した見積もり

見積もりをもっと楽しくする限り、ポーカーを計画してみましたか？それは私が常に複数のチームですべてのスプリントを計画してきた方法であり、すべての人が少なくとも何かを選ぶ必要があるので、全員が関与し続けるのに良い方法です。また、チームの全員が3を選び、誰かが20を押して説明する必要がある場合、またはチームの全員が5を押したがマネージャーが8を押した場合（と議論するつもりの場合）、かなりの量の楽しみがあります彼はあなたにもっと時間を与えたいときに上司！）。

これを行うために必要なのは、いくつかのプランニングポーカーカードです。これは、インデックスカードの裏側でよく作成するか、フェイスカードに値を付けた通常のトランプを使用します。派手なものは何もありません、そして、それは皆に集中し続けます。ポーカーの計画を含め、1日中タスクを実行しようとすると、生産性が低下することを覚えておいてください。多くのカードセットには、理由のためにコーヒーカードが付属しています。誰かが燃え尽きたと感じたら、チームに休憩を与えて充電し、全員が新鮮なときにそれを拾います！

物理的なカードの代替として、電子カードも見ることができます。ここでの本当の利点は、結果の自動追跡、推定されるユーザーストーリーの追跡、および「不正」を回避するために全員が一度にカードを表示できることです（1人の推定は、カードを見ることができるため他の人の影響を受けます）。明らかにこれには誰もがコンピューターと手元のタスクに集中する能力が必要なので、あなた自身の裁量でそれを使用してください。

1. バックグラウンドアイテムがスプリントキックオフの前に挿入および優先順位付けされないのはなぜですか？開発者の時間を無駄にすることは楽しいことではありません。数日前にチームのリーダーがプロダクトオーナーとプロジェクトマネージャーと協力して、優先順位を付けます。これは、各スプリントチームのメンバーの計画にも役立ちます。

2. 物事をタスクに分割するのに1日かかるのはなぜですか？適切な規模のチーム（開発者2〜4人、開発者1人あたり0.5〜1.5 QA、1〜2人）がいる場合、このスプリントで2〜4のユーザーストーリーが必要です。製品所有者が要件を明確にし、30分程度費やしてから、30分程度かけて約8時間のタスクに分けます。会議中にタスクを入力しないでください。チームとして、正気の人々がそれらを理解するのに十分なタスクは何か、誰が責任を持ち、どのくらいの時間を取るべきかについて同意します。「テストにかかる時間」がスプリント内に快適に収まることに同意します。

3. 物事をタスクに分割するだけではない場合、他に何をしていますか？確かに、レトロスペクティブは30〜60分かかることがありますが、チームが溝に入ると短くなります。

要約すると、人々の時間の無駄遣いをやめれば、会議の面倒さは少し減ります。それを超えて、チームでの楽しさと同志は、会議で対処できるものではありません。一緒に昼食に行き、冗談を言って、人々を混ぜ合わせてより良い人格に合わせて、口ひげを生やしているコンテストをしてください。

計画は、チームが多くの柔軟性を持っているスクラムの1つの領域です。あなたのチームに役立つ何かを見つけるまで、スプリントごとに新しいものを試してください。

私が個人的に試した、または他のチームから聞いた成功したアイデア：

• チーム全体でユーザーストーリーの作成と優先順位付けを行います。プロダクトオーナーまたはスクラムマスターは、忙しい作業の多くを処理し、チームに調整させることができます。
• バックログを単一のスプリントよりも大幅に長くします。それを構築するのに時間がかかる場合がありますが、バックログが十分に長い場合、計画会議は小さな調整を行うか、最近のビジネス開発に対処するために削減されます。
• スプリント計画とは別に見積もり会議を開催します。会議が長すぎると人々が考える場合、それらを分割しない理由はありません。
• 具体的には、計画が議題になります。これは、1人または2人のチームメンバーが戻るのを頻繁に待つ場合に便利です。
• ミーティングの途中で休憩し、1つまたは2つのユーザーストーリーを作成するよう全員に割り当てます。その後、再びミーティングを行い、コンセンサスを獲得します。
• 計画会議では、方法ではなく、何をすべきかを確認してください。エンジニアは後者に非常に簡単に陥ります。必要に応じて、方法を議論する個別の設計会議をセットアップします。
• ストーリーを調査と実装に分けます。チームメンバーが作業内容をあまり知らない場合、会議の計画を立てるのに時間がかかりすぎることが多く、会議中にそれを把握しようとします。
  たとえば、チームに経験のないAPIと統合する必要があるとします。計画会議中に無知なことについての見積もりとタスクを作成するのではなく、1つの調査ストーリーを作成してAPIを学習し、シンプルな「hello world」アプリを作成して、チームに教えます。 その後、実際の作業を計画する準備が整います。
• 特定の問題の会議中に追跡します。「計画はつまらない」だけでなく、「不明な要件について多くの時間を費やしており、誰も正しい答えを知らないようです」などの詳細レベルです。その後、振り返りでこれらの特定の問題について話し合い、特定のソリューションについてブレインストーミングします。ピースが簡単に解決されるまで、問題を分解してください。

スプリントプランニングと回顧展を同時に開催し、ほぼ90分で完了しますが、より速いチームの1つです。私たちは、4〜6時間かかる5つのスプリントごとに全社的な長期計画を立てています。もちろん、チームはそれぞれ異なりますが、スプリントごとに1日中過ごす場合、改善の余地がたくさんあります。

計画セッションが長すぎます！

私の経験に基づいて、スプリント計画会議の計画は週に2時間以内に行う必要があります（たとえば、2週間のスプリントには最大で1/2日かかります）。

特定の場合：なぜタスクを見積もるのですか？計画中はストーリーのみを推定する必要があります。タスクは、特定のタスク所有者が後で推定できます。

私のために働いた方法：

• POによるスプリントの簡単な紹介
• スプリント能力の推定
• スプリントをカバーするのに十分なものが推定されるまで、ストーリーは終わり、ポーカーを計画します（ストーリーごとに5/10分でタイムボックス化されます）
• チームによる公式のコミットメント/予測

次に、並行して、ペアで、自分のデスクで自己組織化し、タスクとタスクの見積もりを行います。

私の以前の仕事では、各スプリントの最初の日全体（ここでは反復と呼ばれていました）が次のように取り上げられました。

• 回顧。私たちは最終日の午後にこれを開始しましたが、スプリントについて振り返ってから、そのスプリントの作業の最後のゆるい端を結び付けて仕事に戻ることがよくありましたので、振り返る前に、仕事はすべて私たちの後ろにありました。また、スクラムプロセスのすべての会議オーバーヘッドを統合して、他の日をより理想的な形で計画し、費やすことができるようにすることも論理的に思えました。これには通常2時間かかりました。
• スプリントプランニング。バックログは、マイルストーン計画会議（開発者とPOの両方で1日になることもあります）で推定され、各スプリントの開始前にPOによって優先順位が付けられていました。開発者の日数（休日、バカなど）を把握し、山の頂上でできると思っていた作業を取得し、ユーザー要件（以前はBAにより審査済み）をすばやく確認しましたMPM中の簡単な概要で得られたものよりも、作業に伴うものをより完全に把握します。通常、これにはさらに2時間かかりました。
• タスクプランニング。ストーリーと受け入れ基準を知って、理想的な時間（気を散らすものや障害物なしでそのタスクを「完了」することに専念するのに費やした時間）で、各ストーリーを一口サイズのタスクに分解しました。私たちのポイントスケールが最終的に調整された方法、5は開発者のスプリントでしたので、1は2開発者日までを含むことができます。そのため、チームメンバーがスクラムボードで進捗状況を表示できるようにするには、事実上すべてを分解する必要がありました。これは別の2時間のブロックで、この項目と次の項目の間にはギブアンドテイクがありました。
• AATアウトライン。POとBAはプログラマーではなく、コーディングもしていません。POは、Wordテンプレートの形式で要件を提供し、BAと協力してその形式で要件を改善することを規定する契約の背後に隠れました。BAはコードを理解しましたが、その時間は純粋に分析と最終テストでした（これにはシステムが存在する必要があったため、マクロをSeleniumに記録できました）。したがって、コードが受け入れ基準を満たしていることを確認するには、「紙」受け入れテストのアクションをモデル化する独自のAATを作成する必要がありました。通常は、単体テストと統合テストに使用したのと同じNUnitフレームワークでこれを行いました（FitNesseを試しましたが、十分な速さで断念できませんでした）。これは各スプリントの最初の日の残りであり、2日目まで続きました。

私の現在の仕事では、私たちはまだスクラムプロセスを採用しており、チーム全体のマイルストーン計画はありませんでした。また、現在取り組んでいるものの多くには、厳格な受け入れ基準がありません。ですから、スプリント計画は、各ストーリーが何を意味するのか、何をすべきかを説明するものであり、トップXの理想的な労働時間をトップから奪うというコミットメントです。私たちは社内のチームであり、各自がソフトウェアのエンドユーザーと個人的に協力して要件と設計ソリューションを収集しているため、少なくとも今のところはそれで問題ありません。それでも、スプリント計画は隔週月曜日に午前中に行われ、午後は火曜日に本格的に開発を開始できるようにするために個人的な障害を取り除くことに費やされます。

OPの質問に実際に回答するには、他のコメント/回答とは対照的に、それほど時間をかけてはいけないと言うのではなく、アジャイルの見積もり、スプリントの計画、振り返りにアプローチする方法があります。

特に懸念に対処する：

• 会議は長いです -それらをタイムボックス。各会議は、レトロスペクティブ、スプリントプランニング、タスクブレークダウンなど、明確な目的と議論のトピックを持ち、可能な限り一定の時間に制限する必要があります。スクラムマスターの仕事は、これらの会議をトピックに保ち、時間の目標を達成するために順調に進むことです。

• 会議は単調です -その一部があります。一度に1つのサイズのチャンクで作業しているので、同じことを何度も繰り返します。チームの集中力を維持し、会議の目的を達成するために推進することが役立ちます。

  私が聞く他のことは、多分あなたのスプリント計画会議があまりにも多くを達成しようとしているということです。私の最後の会社では、ストーリーの推定は「マイルストーン計画会議」で行われました。それらの会議では、私たちが見積もっていなかったバックログに蓄積されたすべてのものがポイントで見積もられました。ストーリーの推定をポイント単位で行い、次にタスクの推定を時間単位で行う場合、両方を同時に（おそらく同じ日に）したくないでしょう。

• ストーリーをポイント単位で推定し、その後数時間でタスクを行うことは冗長に思えます。2つの異なる目的があります。ストーリーの推定の目的は、複雑さの大まかな推定値を提供することです。これを使用して、過去の速度と予想される帯域幅に基づいてスプリントバックログを埋めることができます。タスクの見積もりの​​目的は、ストーリーを開発者1日以内に分割することです（したがって、すべてを時間内に完了することが期待される1人の男に割り当てることができます）。ストーリーの複雑さを誤って推定したり、スプリントで噛むことができる以上に噛み砕かれたりしました。

  すべてのストーリーに1日以下かかる場合、それは冗長ですが、すべてのポイントスケールが均等に調整されるわけではありません。私の最後の仕事で、5は開発者2週間でした（最初は多くの叙事詩があったため）。これは線形スケールで最大2開発者日を意味しました。そのような規模を考えると、事実上すべてがタスクに分解されるはずです。私の新しい会社では、ポイントは開発者の半日に近いので、1または2でさえ間違いなく独自のタスクであり、3-8はチームをタスクに分割することに関して不明確です。

• 時間がかかり、人々の集中力が低下し、時間がかかるという悪循環があります-タイムボックス-タイムボックス。コーディングするときと同じように、休憩を取ってください。30分ごとに、5分かけて足を伸ばしたり、グループを変更したりします。1時間ごとに10分にすることもできますが、それ以上の長い会議時間をかけないでください。みんなお腹がすいてきたり、もっとコーヒーが必要だったり、トイレ休憩が必要だったりするかもしれません。あなたが彼らにそれを吸い込ませるならば、あなたは彼らの心がさまようことを見つけるでしょう。先に述べたように、それ以上に、議論を短く、甘く、要点に保つことも助けになります。

スプリント計画会議には2つの部分があります。

1. チームが何をするかを決定する
2. チームがそれを行う方法を決定します。

最初の部分は比較的単純です。チームが引き受けることができると感じるストーリーポイントの数に基づいて、優先順位に従ってその多くのユーザーストーリーを完了することにコミットします。できた

2番目の部分は、開発者が実際に楽しむべきことです。ストーリーの作成とソリューションの設計です。タスクはそれから外れます。そのため、製品所有者、または彼が提供した中小企業に選択したストーリーを説明してもらってください。次に、開発者がそれを引き受けたい場合は、設計の議論を主導します。ホワイトボードを使用します。アイデアをバウンスします。楽しんで。

本当にそれだけです。設計会議が面白くない場合は、何かが間違っているだけです。

ええ、これは古い質問ですが、新しい答えがあります。：P

会議を分割します。

スプリント計画会議を3つの個別のミニ会議に分割しました

• バックログのグルーミング
• ストーリー選択
• タスクの内訳

毎日のスクラムの直後にそれぞれ別の日に行います-毎日のスクラムが完了するとすぐに計画活動に入り、その日の残りの（通常の計画された）会議から解放されます。

だから、私たちは計画をウォーターフォールした：-O

各セッションに関係するものについてはすぐに詳しく説明しますが、どのようにしてこれに到達したかを説明します。

私たちは、あなた自身のように、本当に恐ろしいスプリント計画会議で問題を抱えていました。適切な要素はすべて揃っていましたが、すべてが永遠に続き、精神的にも精神的にも疲れ切っていました。

その後、Pivo​​talの毎日5分のBusiness Insiderの記事を読んで、会議を短いセッションに分割し、毎日の始めに行うというアイデアを得ました。

私はそれを回顧展でチームと共に持ち出しました。すぐに気に入ったチームメンバーもいれば、少し不安だったチームメンバーもいましたが、インターンはポモドーロテクニックについて読んだ研究に言及し、それについて研究を始めました。

だから私たちはそれを試してみることにしました。
2時間の会議を3つの25分のセッションに分けました。（はい、それはあいまいな数学ですが、誰もが私たちの会議が長すぎると感じ、時間を節約した場合にのみそれをしたかったです）。

そしてうまくいきました！約6週間、2つの別個のプロジェクト（合計2週間のスプリント6つ）でそれを行っており、世界に差をつけています。
生産性が向上します。時間を大幅に節約できます。
より良い出力が得られます。そして、私たちはもはや計画会議を恐れません。

正直なところ、25分のタイムボックスはかなり緩いです。一部のセッションはグルーミングセッションの5〜10分など非常に速くなり、一部のセッションは新しいストーリーを特定したり、ストーリーを分割しなければならない場合などに長くなります。交渉中に再評価します。全体的には、それは通常、シバン全体で平均して1.5時間以下であり、それがとてもうまく機能する理由だと思います。

詳細については.....

バックログのグルーミング

非常に簡単です-私たちは最優先のストーリーをレビューし、それらが伴うものについて話し、そして私たちの見積もりが良いことを確認します。

必要に応じてストーリーを再評価します。たとえば、数か月前に見積もったように、同様のストーリーが実際に何をしたかを理解した後、再評価することに同意するかもしれません。（ちなみにユニットなしのストーリーポイントを使用し、タスクを推定しません）。

また、POが優先度が高いと感じた新しいストーリーを追加した場合、これがそれらを推定する時間です。

ストーリーの選択は翌日まで行われないため、このプロセスにより、POが次の反復で行うことが最も重要なことを最終的に判断するための少し余分な時間が与えられます。これは非常に有用です。

この会議は、一部のPOでは不足し、他のPOでは長くなる傾向があります。（個人的に、私はそれがあなたのPOがどのようにやっているかの素晴らしい匂い指標だと思います）

ストーリーセレクション

Chris Vossを入手して、交渉の時間です。

この会議では、最優先のストーリーを取り上げ、それぞれのDoDを定義します。スプリントの目標に全員が同意するまで、それぞれが何を伴うか（必要に応じてストーリーを分割および結合する）を交渉します。

私たちは、新鮮な心とこのミーティングの良い朝のエネルギーから多くの恩恵を受けます-そして、私たちが別の日に仕事をすることを知っていると、本当にうまく交渉し、コミットメントを理解するために必要な時間を費やすことができます。

タスク

わかりましたので、私が言って最初のでしょう、タスクは私だったLEAST私たちの古い1日の会議で計画の好きな部分は。

私達はこれで私達の歩みを決して打たない。私たちは会議の終わりまでタスクを保存しようとしましたが、それまでにすべてが使い果たされ、本当に非生産的でした。交渉中にDoDと同時にタスクを定義しようとしましたが、気が散りすぎて面倒すぎることがわかりました。すべてのストーリーを選択する前に燃え尽きてしまいました。また、見積り、交渉、ストーリー選択、タスク生成の間でフォーカス/思考を切り替えることは本当に困難でした。私たちは苦労し、それはひどく、会議は恐ろしくなりました。

しかし今では、DoDを1日で定義し、次の日までタスクを実行しないことで、私たちは燃え尽きることなく、常に正しい心構えにいます。始める前にすべてのタスクを熟考し、理解してください。

これだけで、私見は完全なゲームチェンジャーです。

すべてを一緒に入れて。

それで、スプリントセレモニーのスケジュールは次のようになります。

• 月曜日-毎日のスクラム->スプリントレビュー
• 火曜日-毎日のスクラム->バックロググルーミング
• 水曜日-毎日のスクラム->ストーリーの選択
• 木曜日-毎日のスクラム->タスク
• 金曜日-デイリースクラム->回顧

それは私たちにとって本当にうまくいきました。試してみたら、あなたの意見を聞いてみたい。

毎週のスプリントで1時間のミーティングを行い、前のスプリント、何をすべきか、そして次の週の計画に移ります。すべて1時間以内。

これはもちろん、スクラムを厳しく追跡しすぎると時間を浪費するだけであることがわかったためです。これは、リクエスターがユーザーストーリーを作成するときに、ほとんどのストーリーがチームメンバーと既に議論されているためです。

あなたのチームが会議の計画を恐れるなら、おそらくスクラムの「ルール」のいくつかを手放すべきだと言っています。

この質問は包括的に回答されていますが、それを機能させて楽しくするために必要なことは1つだけです。

チームに力を与えます。-つまりは、彼らがいることをものに動作させる、彼らが最も重要だと思います。