スプリント計画を楽しくする方法
私たちのスプリント計画会議は面白くないだけでなく、実に恐ろしいです。
会議は退屈で退屈で、永遠にかかります（1日ですが、ずっと長く感じます）。
開発者はそれについて不満を述べ、今後の計画を恐れています。
私たちのルーチンはかなり標準的です（ユーザーストーリーが優先度でスプリントバックログに挿入されます>>ストーリーはタスクに分解されます>>タスクは数時間で推定されます>>繰り返し）私たちは何が間違っているのか理解できません。
どうすれば会議をより楽しくすることができますか？
...
詳細情報のリクエストに応じて、さらに詳細を説明します。
スプリントキックオフの前にバックログアイテムが挿入および優先されないのはなぜですか？
ユーザーストーリーは確かに優先されます。それらをタスクに分解するまでにどのくらい時間がかかるかはわかりません！ここでの（優れた）回答から、おそらくユーザーストーリーだけでタスクを見積もるべきではないことがわかります。ストーリーではなくタスクを見積もる理由は、ストーリーの見積もりがひどく間違っているためです。しかし、それがまったく別の問題の主題だと思います。
開発者が不満を言うのはなぜですか？
会議は長いです。
会議は単調です。ストーリーごと、タスクごと、苦労して（はい、苦労して）どれだけの時間がかかり、何が関係しているかを見積もる。
タスクを見積もると、ユーザーストーリーの推定は無意味に見えます。
会議が長くなるほど、会議室の焦点が少なくなります。集中力の低い同僚ほど、会議にかかる時間が長くなります。再帰的なヘイトスパイラルが発生します。人々を集中させるために、会議を2日間に分割することを検討しましたが、開発者はそれを聞きませんでした。計画の1日は十分に悪いです。 two？
私たちの問題の一部は、（より正確な推定値を得るために）非常に小さな詳細に入るということです。しかし、大まかに見積もると、私たちはかなり外れます！
質問をまとめると：
何が悪いのでしょうか？
会議をより楽しいものにするために、他にどのような方法がありますか？
見積もりを簡単にする
スプリントの計画を打ち破ります。
個々のタスクを見積もる必要がありますか？私はスプリント計画を2つの方法で行いました：
- ストーリーはストーリーポイントで推定され、タスクは時間で推定されます
- ストーリーはストーリーポイントで推定され、タスクは推定なしで単にその下にあります
2つのうち、私は2番目のオプションを好みます。 タスクを推定しないことで、変更に対処する開発者の自由度が高まることがわかります。タスクが意味をなさなくなった場合（何回、タスクは適用されないか、以前のスプリントですでに実行されています）、ペナルティなしで単にそれを捨てるか、または現在のタスクを何か新しいものに変更しなければならない場合があります。タスクの合計がストーリーポイントを表す必要があり、その逆もあるので、両方を見積もると、本当に冗長になります。これによって、個々のタスクにかかる時間を知る以外に、どのような価値がありますか？違いを生み出すのに十分に異なるタスクサイズを使用している場合は、それらのタスクをより小さく、より均一なチャンクに分割することをお勧めします。
これにより、スプリントの計画に費やす時間を短縮できます。ストーリーはスプリントの計画中に推定され、スプリントを開始するときに、そのストーリーを構成する、考えられるすべてのタスクを書き留めることができます。明らかに、あなたが知っているストーリーを推定するときに遭遇するポイントがある場合、タスクで処理する必要があるは、ストーリー情報に追加して、次のように配置できます。仕事。
理想的な単位で推定
ストーリーポイントは、理想的な労働時間や理想的な労働日など、理想的な単位であることが意図されています。これらは、中断や会議がなく、すべてが計画どおりに進んだ完璧な1日で、X日でタスクを完了することができることを意味します。誰もがこれが単に真実ではないことを知っていますが、統計についての素晴らしいことは、そうである必要がないということです。
つまり、理想的な日にこれらを推定してしばらくすると、ストーリーを完成させるのに平均で推定した時間の25％余分にかかることがわかります。理想的な4営業日を見積もり、代わりに5日かかったとしましょう。時間が経つにつれ、これを追跡し、理想的な日から実際の日への変換の大まかな考えがわかります。あなたの最初の本能は、過大評価することによってこれを補償しようとすることであり、おそらくあなたは間違っているでしょう。ここでの主なことは、一貫性を保つことです。このようにして、長期平均は同じままです。確かに時々、それは下になることもあれば、終わることもありますしかし、あなたが見積もるほど、あなたはより良い状態になります。あなたstillはまともな見積もりを取得できません。おそらくそれは、ストーリーを適切に見積もるのに十分な知識がないことを意味します。
ストーリーについて話す
あなたが見積もるとき、誰もが何が必要か、最初から最後まで、このストーリーに何が必要かについておおまかな考えを持つべきです完全であること。すべての詳細を知る必要はありませんが、あなた自身が物語を引き受けることができると考えるのに十分です。そのレベルの自信がない場合は、おそらくそれを推定するべきではありません。 「このストーリーは大きすぎて詳細のほとんどを知ることができない」と言った場合、それはストーリーが大きすぎて、分解する必要があることを示しています。少なくとも私の経験では、ストーリーは小さいので、必要に応じて1人で1人で作業し、1〜2週間で完了できます。
これは、編集の2番目のポイント、つまり見積もりが多すぎるの解決にも役立ちます。ストーリーごとにすべてのタスクを見積もるのではなく、ストーリー全体を見積もるだけで、見積りの多くを取り除くのに役立ちます。ミーティングの単調さを減らすために、ポーカーを計画することをお勧めします。ポーカーについては、上記の詳細をご覧ください。
計画をより魅力的にする
プランニングポーカーを使用した見積もり
試してみましたか？ planning poker ？これは、私が常に計画を立ててきた方法ですすべての私のスプリントは複数のチームにあります。すべての人が少なくとも何かを選ばなければならないので、それは全員を関与させ続けるのに良い方法です。チームの全員が3を選び、誰かが20を置いて自分自身を説明しなければならないとき、またはチームの全員が5を置いたがマネージャーが8を置いたとき（それは議論するつもりだ）ボスがあなたにもっと時間を与えたいとき！）.
これを行うには、必要なのは、いくつかの計画用ポーカーカードだけです。これは、インデックスカードの裏側によく作成するか、値を持つ通常のトランプを使用しますフェイスカードに付属。特別なことは何もありません。 （ポーカーの計画を含めて）1日中タスクを実行しようとすると、生産性が低下することを覚えておいてください。多くのカードセットには、理由によりコーヒーカードが付属しています。誰かが燃え尽きてきたと感じた場合は、チームに再充電のための休憩時間を与え、全員が新鮮なときにそれを拾ってください！
物理カードの代わりに、 電子カード も確認できます。ここでの真のメリットは、結果の自動追跡、推定されるユーザーストーリーの追跡、および「チート」を回避するために全員が一度にカードを表示できることです（ある人の推定は、自分のカードを見ることができるために他の人の影響を受ける）。もちろん、これには誰もがコンピューターと目の前のタスクに集中できる能力を持っている必要があるので、自分の裁量でそれを使用してください。
スプリントキックオフの前にバックログアイテムが挿入および優先されないのはなぜですか？開発者の時間を無駄にするのは楽しいことではありません。数日前に、チームをリードして製品の所有者およびプロジェクトマネージャーと作業を進め、優先順位を付けます。これは、各スプリントチームのメンバーの計画にも当てはまります。
物事をタスクに分割するのに1日かかるのはなぜですか？適度な規模のチーム（開発者2〜4人、開発者あたり.5〜1.5 QA人、その他1〜2人）の場合は、このスプリントには2〜4のユーザーストーリーがあります。製品の所有者が要件を明確にした状態で30分ほど費やしてから、30分ほどで最大8時間のタスクに分割します。 会議中にタスクを入力しないでください。チームとして、正気な人がタスクを理解するのに十分であり、タスクの責任者であるタスクに同意する、そして彼らがかかる時間について。 「テストにかかる時間」がスプリント内に快適に収まることに同意します。
物事を単にタスクに分解するだけではない場合、他に何をしていますか？確かに、回顧は30〜60分かかることがありますが、チームが溝に入るにつれて短くなります。
要約すると、人々の時間を無駄にするのをやめると、彼らは会議を少し恐れるでしょう。それ以上に、チームでの楽しさと思いやりは、会議で対処できるものではありません。一緒に昼食に出かけたり、冗談を言ったり、人を混ぜ合わせて性格を合わせたり、口ひげを生やしたりするコンテストを開催したりします。士気が上がると、スプリント計画の会議をより気軽にできるようになります。
プランニングはスクラムの1つの領域であり、チームには多くの柔軟性があります。チームに役立つ何かにぶつかるまで、すべてのスプリントで新しい何かを試してください。
私が個人的に試した、または他のチームから聞いたいくつかの成功したアイデア：
- チーム全体ではなく、ユーザーストーリーの作成と優先順位付けを行います。製品の所有者やスクラムマスターは、忙しい作業の多くを処理し、チームに調整させることができます。
- バックログを1つのスプリントよりも大幅に長くします。構築に時間がかかる場合がありますが、バックログが十分に長い場合、会議の計画は、わずかな調整を行うか、最近のビジネス開発に対応するために削減されます。
- スプリント計画とは別の見積もり会議を行います。会議が長すぎると思われる場合、会議を分割しない理由はありません。
- 具体的には、計画が議題に入ります。これは、1人または2人のチームメンバーが戻るのを待つのに時間を浪費している場合に役立ちます。
- 会議の途中で休憩し、全員に1つまたは2つのユーザーストーリーのタスクを割り当てます。その後、会議に戻って報告し、コンセンサスを得ます。
- 計画会議がwhatではなく、（）についてであることを確認してください。エンジニアは後者に簡単に陥ります。必要に応じて、個別に設計会議を開き、方法について話し合います。
- ストーリーを調査と実装に分けます。計画会議は、チームメンバーが作業内容についてほとんど理解していない場合に長すぎて、会議中にそれを理解しようとすることがよくあります。
たとえば、チームで経験のないAPIと統合する必要があるとしましょう。計画会議中に無知なことについて見積もりやタスクを作成するのではなく、調査ストーリーを1つ作成してAPIを学習し、簡単な「Hello World」アプリを実行して、チームに教えます。 その後実際の作業を計画する準備が整います。 - 特定の問題の会議中に追跡します。 「計画はつまらない」だけでなく、「不明確な要件について多くの時間を費やしており、正しい答えをだれも知らないようです」のような詳細レベル。次に、それらの特定の問題を回顧で話し合い、特定の解決策についてブレインストーミングを行います。簡単に解けるようになるまで問題を分解します。
私たちはスプリントの計画と振り返りを同時に行い、ほとんどの場合90分で完了しますが、私たちはより速いチームの1つです。私たちは、全社規模の大規模な長期計画を5スプリントごとに4〜6時間かかります。もちろん、チームはそれぞれ異なりますが、すべてのスプリントで1日中過ごしている場合は、改善の余地がたくさんあります。
計画セッションが長すぎます！
私の経験に基づいて、スプリント計画会議は、計画されている週に2時間以下かかるはずです（たとえば、2週間のスプリントは最大で1日かかるはずです）が、成功するものはそれよりも短いはずです（その半分）。
あなたの特定のケースでは、なぜタスクを見積もるのですか？計画時にはストーリーのみを見積もる必要があります。タスクは特定のタスク所有者によって後で見積もることができます。
私のために働いた方法：
- POによるスプリントの簡単な紹介
- スプリント容量の見積もり
- スプリントをカバーするのに十分な推定されるものがなくなるまで、ストーリーはダウンしてポーカーを計画します（ストーリーごとに5/10分でタイムボックス化）。
- チームによる公式のコミットメント/予測
次に、並列/ペア/自分のデスクで組織化され、タスクとタスクの見積もり。
私の前の仕事では、各スプリントの最初の日全体（ここでは反復と呼びました）は次のように扱われました。
- Retrospective。私たちは最終日の午後にこれを始めましたが、スプリントについて振り返って、そのスプリントの作業の最後のゆるい結末を縛って仕事に戻ることがよくありました。振り返る前に、すべての作業が私たちの背後にあることを確認した方がよいと考えました。また、スクラムプロセスのすべての会議オーバーヘッドを統合して、他の日をより理想的な形で計画して費やすことができるようにすることも当然のように思われました。これには通常2時間かかりました。
- スプリント計画。バックログは、マイルストーン計画会議中に見積もられ（開発とPOの両方にとってそれ自体が1日である可能性があります）、各スプリントの開始前にPOによって優先順位が付けられていました。開発者が利用できる開発者の日数（休日、vacaなどの計算）を把握し、山の頂上から実行できると思われる作業を取得し、ユーザーの要件（以前はBAで検証済み）をすばやく確認しました。 MPM中の簡単な概要よりも、作業に必要なものをより完全に理解できます。これには通常、さらに2時間かかりました。
- タスクプランニング。ストーリーと受け入れ基準を把握し、各ストーリーを理想的な時間（そのタスクを「実行」することに集中するだけで1時間を費やすことに集中した） 。私たちのポイントスケールが最終的に調整された方法では、5は開発者スプリントだったので、1は最大2開発者日を含む何でもかまいません。そのため、チームメンバーがスクラムボードで進行状況を表示できるようにするには、事実上すべてを分解する必要がありました。これは別の2時間のブロックであり、これと次の項目との間のギブアンドテイクがありました。
- AATの概要。私たちのPOとBAはプログラマではなく、コーディングもしていません。 POは、Wordテンプレートの形式で要件を提供し、BAと協力してその形式で要件を調整することを規定する契約の背後に隠れていました。 BAはコードを理解していましたが、その時間は純粋に分析と最終テストでした（システムを存在させる必要があったため、マクロをSeleniumに記録できました）。したがって、コードが受け入れ基準を満たしていることを確認するために、「ペーパー」受け入れテストのアクションをモデル化した独自のAATを作成する必要がありました。通常、これは単体テストと統合テストに使用したのと同じNUnitフレームワークで実行しました（FitNesseを試しましたが、十分に速くあきらめることができませんでした）。これは、各スプリントの1日目の残りの日であり、2日目まで続きました。
私の現在の仕事では、私たちはまだスクラムプロセスを採用しており、チーム全体のマイルストーン計画はありませんでした。そして、私たちが取り組んでいることの多くは、厳密な受け入れ基準を持っていません。したがって、私たちのスプリント計画は、それぞれのストーリーが何を必要とし、何を行うかを説明するものです。これは、トップXの理想的な作業時間を達成するための取り組みです。私たちは社内チームであり、私たち一人ひとりがソフトウェアのエンドユーザーと個人的に協力して要件を収集し、ソリューションを設計しているため、私たちはそれを回避します。それでもスプリントの計画は毎週月曜日の午前中のことであり、午後は火曜日に本格的に開発を始めることができるように個人的な障害をすべてクリアします。
それほど長くはかからないと他のコメント/回答を対比させるのではなく、実際にOPの質問に答えるには、アジャイル推定、スプリント計画、およびレトロスペクティブにアプローチする方法があり、使用するよりも少し興味深いものがあります。
具体的にあなたの懸念に対処します：
ミーティングが長い-タイムボックスでミーティング。振り返り、スプリントの計画、タスクの内訳など、各会議には明確な目的と議論のトピックがあり、できるだけ一定の時間に制限する必要があります。スクラムマスターの仕事は、これらの会議をトピックごとに維持し、時間の目標を達成するために順調に進むことです。
ミーティングは単調です-いくつかあります;一口サイズのチャンクを1つずつ作業しているので、同じことを何度も繰り返します。チームを集中させ、ミーティングの目的の達成に向けて推進することが役立ちます。
私が聞いた他の何かは、おそらくあなたのスプリント計画会議があまりにも多くを達成しようとしているということです。私の最後の会社では、ストーリーの見積もりは「マイルストーン計画会議」で行われました。それらの会議では、私たちが見積もっていなかったバックログに蓄積されたすべてがポイントで見積もられました。ポイント単位でストーリーの見積もりを行ってから、時間単位でタスクの見積もりを行う場合、両方を同時に（おそらく同じ日に）行う必要はありません。
ストーリーをポイントで見積もると、時間単位のタスクは冗長に見えます-彼らには2つの異なる目的があります。ストーリー推定の目的は、過去の速度と予想される帯域幅に基づいてスプリントバックログを埋めるために使用できる複雑さの大まかな推定を提供することです。タスクの見積もりの目的は、ストーリーを1開発日またはそれ以下かかるものに分解し（したがって、すべてを時間内に完了することが期待される1人の担当者に割り当てることができます）、ストーリーの複雑さを誤って推定したり、スプリントでかみ砕く以上に噛み砕いたりした。
ストーリーのすべてに1日以下かかる場合は冗長ですが、すべてのポイントスケールが同じように調整されているわけではありません。私の最後の仕事では、5は2週間の開発者でした（最初は見積もる叙事詩が多かったため）。これは、線形スケールで最大2開発者日までのポイントになります。この種の規模を考えると、事実上すべてがタスクに分解されるはずです。私の新会社では、ポイントは開発者の半日に近いので、1または2は間違いなく独自のタスクであり、3〜8はチームにそれをタスクに分割することを強制することに関して曖昧です。
時間がかかる悪循環があり、人々の集中力が低下するため、時間がかかります-タイムボックスタイムボックス。コーディングするときのように、休憩を取ってください。 30分ごとに、5分かけて脚を伸ばしたり、グループを組み直したりします。1時間ごとに10分にすることもできますが、それよりもはるかに長い会議時間をプッシュしないでください。あなたの部下は空腹になっているかもしれませんし、もっとコーヒーを必要としているかもしれません、またはトイレ休憩など。それらを否定しないでください。あなたが彼らにそれを吸い込ませたら、あなたは彼らの心がさまよっているのを見つけるでしょう。それ以上に、前述のように、ディスカッションを短く、甘く、適切に保つことも役立ちます。
スプリント計画会議は2つの部分に分かれています。
- チームが何をするかを決める
- チームがそれを行う方法を決定します。
最初の部分は比較的単純明快です-チームが引き受けることができると感じるストーリーポイントの数に基づいて、優先順位でその多くのユーザーストーリーを完了することへのコミットメント。できました。
2番目の部分は、開発者が実際に楽しむべきもの、つまりストーリーの詳細とソリューションの設計です。タスクはそれから落ちます。したがって、製品の所有者、またはSME彼は選択したストーリーについて説明してくれました。それから、開発者がそれを引き受けたいと思う人は誰でも、デザインディスカッションをリードしてください。ホワイトボードを使用してください。アイデアをバウンスしてください。 。 楽しんで。
それだけです。設計会議が面白くない場合は、何か問題があるだけです。
ええ、これは古い質問であることは知っていますが、新しい答えがあります。 ：P
会議を分割します。
スプリント計画会議を3つの別々のミニミーティングに分割しました
- バックログのグルーミング
- ストーリーセレクション
- タスクの内訳
私たちは毎日、毎日のスクラムの直後に別の日に行います。毎日の作業が完了するとすぐに、計画活動にすぐに参加し、その日の残りの（通常の計画された）会議から解放されます。
そうそう、私たちは私たちの計画を滝のようにしました：-O
各セッションで何が行われるかについては、後で詳しく説明しますが、どのようにしてこれに到達したかを説明しましょう。
私たちも、あなた同様、本当に恐ろしいスプリント計画会議に問題がありました。私たちはすべての適切な要素を持っていましたが、すべてが永遠にかかっただけであり、それを乗り越えるには本当に精神的および感情的に消耗していました。
それから私は Pivotalの毎日5分のこのBusiness Insiderの記事 を読んだ後にこのアイデアを得ました==会議をより短いセッションに分割し、毎日の初めにそれらを行うことについて。
ふりかえってチームと一緒に育てました。チームメンバーの中にはすぐにそれを気に入った人もいれば、少し不安だった人もいますが、私たちのインターンは、彼が読んだいくつかの研究について言及しました pomodoroテクニック についてそれを進め始め、それがアイデアを大いに導いた。
だから私たちはそれを試すことにしました。
2時間の会議を3つの25分のセッションに分割しました。 （はい、それはあいまいな計算ですが、誰もが私たちの会議は長すぎると感じ、時間を節約した場合にのみそれを実行したいと考えました）。
そしてそれはうまくいった！私たちは2つの別々のプロジェクト（合計2週間のスプリントを6つ）でこれを約6週間行っており、それは世界に違いをもたらしました。
私たちはより生産的です。時間を大幅に節約できます。
より良い出力が得られます。そして、私たちは計画会議を恐れることはもうありません。
正直なところ、25分のタイムボックスはかなり緩やかです。一部のグルーミングセッションでは5〜10分のような非常に高速なセッションもあれば、新しいストーリーを特定したり、ストーリーを分割しなければならない場合など、長時間かかるセッションもあります。交渉中に再推定します。しかし、全体としては、通常、シバン島全体の平均時間は1.5時間以内であり、それが非常にうまく機能している理由だと思います。
詳細に.....
バックログのグルーミング
非常に単純です。私たちは最優先のストーリーを確認し、それらが何を伴うかについて話し、見積もりが適切であることを確認します。
必要に応じてストーリーを再推定します。たとえば、数か月前に推定したもののように、類似のストーリーが実際に何をしたかを理解した後で、再推定することに同意する場合があります。 （私たちは ユニットのないストーリーポイント を使用し、そして タスクを推定しない ）を使用します。
また、POが彼が優先度が高いと感じる新しいストーリーを追加した場合は、それらを推定する時です。
ストーリーの選択は翌日まで行われないため、このプロセスによりPOは次の反復で何を行うことが最も重要であるかを最終的に判断するために少し余分な時間を与えます-これは非常に役立ちました。
この会議は、一部のPOでは不足し、他のPOでは長くなる傾向があります。 （個人的には、POの状態を示す良いにおいのインジケーターだと思います）
ストーリーセレクション
Chris Voss をオンにして、交渉の時間です。
この会議では、最優先のストーリーを取り上げ、それぞれに DoD を定義します。全員がスプリントの目標に同意できるようになるまで、必要に応じてストーリーを分割して組み合わせるという、それぞれが何を伴うかについて交渉します。
私たちは新鮮な心を持ち、この会議でおはようございますエネルギーから多くの恩恵を受けます。また、別の日にタスクを実行することを知っていることで、本当にうまく交渉し、コミットメントを理解するために必要な時間を費やすことができます。
タスク
さて、私が最初に言うように、タスクは私の[〜＃〜]最も少ない[〜＃〜]以前の1日の会議での計画のお気に入りの部分でした。
私たちはこれで私たちのストライドを打ったことがありません。会議の終わりまでタスクを保存しようとしましたが、それまでに全員が枯渇し、本当に非生産的でした。私たちは交渉中にDoDと同時にタスクを定義しようとしましたが、それはあまりに煩わしくて面倒であることに気づきました。また、見積もり、交渉、ストーリーの選択、タスクの生成の間でフォーカス/思考を切り替え続けることは本当に大変でした。私たちは奮闘しました、そしてそれは吸いました、そしてそれは私たちの会議を恐ろしくしました。
しかし、ある日にDoDを定義し、次の日までタスクを実行しないことにより、燃え尽きることはなく、常に適切なマインドステートであり、ストーリーを熟考し、開始する前にすべてのタスクをじっくりと考え、理解することができます。
これだけでも、私見は完全なゲームチェンジャーです。
すべてを一緒に入れて。
だから、これが私たちのスプリントセレモニースケジュールが今どのように見えるかです：
- 月曜日-毎日のスクラム->スプリントレビュー
- 火曜日-毎日のスクラム->バックログのグルーミング
- 水曜日-毎日のスクラム->ストーリーの選択
- 木曜日-毎日のスクラム->タスク
- 金曜日-毎日のスクラム->回顧
それは私たちにとって本当にうまくいきました。それを試してみたら、私はあなたの考えを聞きたいです。
私たちは毎週のスプリントを行っており、1時間のミーティングで前のスプリント、何をすべきかについて話し合い、次の週の計画に進みます。すべて1時間以内。
これはもちろん、私たちの場合、スクラムを厳密にフォローしすぎると時間を無駄にしすぎるだけであることがわかったためです。これは、リクエスタがユーザーストーリーを作成するときに、ほとんどのストーリーがすでにチームメンバーと話し合っているためです。
私が言っているのは、もしあなたのチームが会議の計画を恐れるなら、おそらくスクラムの「ルール」のいくつかを手放すべきだということです。
この質問は包括的に回答されていますが、機能させて楽しくするために必要なことは1つだけです。
チームに力を与える-つまり、彼らが最も重要だと思うことに取り組んでもらいます。