スプリント計画を楽しくする方法
-
29-09-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私たちのスプリント計画会議は楽しくないだけでなく、まったく恐ろしいものです。
会議は退屈で退屈で、永遠に時間がかかります（1日ですが、もっと長く感じます）。
開発者たちはそれについて不満を言い、今後の計画に懸念を抱いています。
私たちのルーチンは非常に標準的なものであり (ユーザー ストーリーが優先度に従ってスプリント バックログに挿入される >> ストーリーがタスクに分解される >> タスクが時間単位で見積もられる >> 繰り返す) ため、何が間違っているのかわかりません。
どうすれば会議をもっと楽しくできるでしょうか？
...
詳細情報のリクエストに応じて、さらに詳細をいくつか示します。
スプリントのキックオフ前にバックログ項目が挿入されず、優先順位が付けられないのはなぜですか?
確かにユーザーストーリーは優先されます。タスクに分割するまではどれくらい時間がかかるかわかりません。ここでの（素晴らしい）回答から、おそらくタスクをまったく見積もるべきではなく、ユーザーストーリーのみを見積もるべきであることがわかります。私たちが (ストーリーではなく) タスクを見積もる理由は、ストーリーの見積もりがひどく間違っているからです。しかし、それはまったく別の質問の主題だと思います。
なぜ開発者は苦情を言うのでしょうか？
会議は長いです。
会議は単調だ。物語に次ぐ物語、次から次へとタスク、どれくらいの時間がかかるのか、何が含まれるのかを見積もるのに苦労しています（そうです、苦労しています）。
タスクを見積もると、ユーザーストーリーの見積もりが無意味に見えます。
会議が長くなるにつれて、会議室の集中力は低下します。同僚の集中力が低いほど、会議にかかる時間は長くなります。憎しみのスパイラルが再発する。人々の集中力を保つために、会議を 2 日に分けて行うことを検討しましたが、開発者はそれを聞き入れませんでした。計画を立てるのは 1 日では十分ではありません。今、私たちは持っています 二?!
私たちの問題の一部は、(より正確な推定値を得るために) 非常に細かい部分にまで踏み込んでしまうことです。しかし、大まかに見積もると、大きく外れてしまいます。
質問を要約すると次のようになります。
私たちの何が間違っているのでしょうか？
会議をより楽しくするために、他にどのような方法があるでしょうか?
解決
見積りを簡単に
スプリント計画を細分化します。
あなたは 必要 個々のタスクを見積もるには?私は次の 2 つの方法でスプリント計画を実行しました。
- ストーリーはストーリー ポイントで見積もられ、タスクは時間で見積もられます。
- ストーリーはストーリー ポイントで推定され、タスクは単純に推定なしでそれに該当します。
2 つのうち、私は 2 番目のオプションを好みます。 タスクを見積もらないことで、開発者が変更に対処する自由度が高まることがわかりました。 タスクが意味をなさなくなった場合 (そのタスクが適用できないこと、または前のスプリントですでに完了していることに何度気づいたことでしょう)、ペナルティなしで単純にタスクを破棄するか、現在のタスクを次のタスクに変更する必要があるかもしれません。何か新しいこと、もしかしたらそれを壊してしまうかもしれない。タスクの合計がストーリー ポイントを表す必要があり、その逆も同様であるため、両方を見積もると本当に冗長になります。個々のタスクにかかる時間を知ること以外に、これによって実際にどのような価値が得られるのでしょうか?違いを生むほどタスクのサイズが大きく異なることに気付いた場合は、それらのタスクをより小さく均質な部分に分割することをお勧めします。
こうすることで、次のことが可能になります スプリント計画に費やす時間を削減する. 。ストーリーはスプリント計画中に推定され、スプリントを開始するときに、そのストーリーを構成する考えられるすべてのタスクを書き留めることができます。明らかに、ストーリーを推定する際に遭遇するポイントがある場合は、 知る タスクで処理する必要がある場合は、それをストーリー情報に追加してタスクとして配置できます。
理想単位での推定
ストーリー ポイントは次のとおりです。 理想的 単位 理想的な工数や理想的な勤務日数など。これらは、毎日が完璧な日であり、中断や会議がなく、すべてが計画通りに進んだ場合、そのタスクを X 日で完了できることを意味します。これが単純に真実ではないことは誰もが知っていますが、統計の素晴らしい点は、必ずしも真実である必要はないということです。
これが言いたいのは、理想的な日にこれらをしばらく見積もると、おそらくストーリーを完了するまでに平均で見積もった時間の 25% 余分に時間がかかることに気づくということです。理想的な勤務日数を 4 日と見積もっていましたが、代わりに 5 日かかったとします。時間をかけてこれを追跡すると、理想的な日数から現実の日数への変換の大まかなアイデアが得られます。あなたの最初の本能は、過大評価することでこれを補おうとするでしょうが、おそらく間違っています。ここで重要なことは、 一貫性を保ちます。 そうすれば、長期的な平均は変わりません。確かに、時には終わることもあるし、終わることもある、 しかし、見積もりが多ければ多いほど、より良い結果が得られます。 あなたがそれを見つけたら、 まだ 適切な見積もりが得られません。おそらく、それは、ストーリーについて正しく見積もりを立てるのに十分な知識がないことを意味します。
物語について話す
見積もってみると、 誰もが何をしなければならないかについて大まかなアイデアを持っているはずです。 最初から最後まで、この物語が完了するまでに何が必要かについて説明します。すべての詳細を知る必要はありませんが、自分自身でもストーリーを引き受けることができると思われる程度には十分です。そこまでの自信がない場合は、おそらく推定しないほうがよいでしょう。「この話は大きすぎて詳細をほとんど知ることができません」と言う場合、それは話が大きすぎるため、分割する必要があることを示しています。少なくとも私の経験では、ストーリーは十分に小さいため、必要に応じて 1 人で作業し、1 ～ 2 週間以内に完了できます。
これは、編集の 2 番目のポイントを解決するのにも役立ちます。 見積もりが多すぎる. 。ストーリーごとにすべてのタスクを見積もるのではなく、単純にストーリー全体を見積もるだけで、多くの見積もりを省略できるはずです。会議を単調にしないためには、ポーカーを計画することをお勧めします。詳細については上記をご覧ください。
計画をより魅力的にする
プランニングポーカーによる見積り
見積りをもっと楽しくするために、 やってみました ポーカーの計画? これは、私が常に複数のチームですべてのスプリントの計画を立ててきた方法であり、全員が少なくとも何かを選択する必要があるため、全員を参加させる良い方法です。チームの全員が 3 を選んで、誰かが 20 を付けて説明しなければならないときや、チームの全員が 5 を付けたのにマネージャーが 8 を付けたとき (誰が議論するのか) にも、かなりの楽しみが含まれています。上司があなたにもっと時間を与えたいとき！）。
これをする、 必要なのは計画用のポーカー カードだけです, 、インデックスカードの裏側に作成するか、絵札に値が付いた通常のトランプを使用することがよくあります。派手なことは何もなく、全員が集中できます。何かのタスク (ポーカーのプランニングを含む) を 1 日かけて実行しようとすると、生産性が低下するということを覚えておいてください。多くのカード セットには理由があってコーヒー カードが付属しています。誰かが燃え尽きたと感じたら、チームに充電のための休憩を与え、全員がフレッシュなときに再開してください。
物理カードの代替として, 、あなたも見ることができます 電子カード. 。ここでの本当の利点は、結果の自動追跡、推定するユーザー ストーリーの追跡、および「不正行為」（ある人の推定が自分のカードを見ることができるために別の推定の影響を受けること）を避けるために全員が一度にカードを提示できることです。ただし、これには全員がコンピューターを持ち、目の前のタスクに集中できることが必要であることは明らかなので、ご自身の判断で使用してください。
他のヒント
スプリントのキックオフ前にバックログ項目が挿入されず、優先順位が付けられないのはなぜですか? 開発者の時間を無駄にするのは楽しいことではありません。チームリーダーは数日前にプロダクトオーナーやプロジェクトマネージャーと協力して優先順位を決めましょう。これは、各スプリント チームに誰が参加するかを計画する場合にも当てはまります。
物事をタスクに分割するのになぜ 1 日かかるのでしょうか? 適度な規模のチーム (開発者 2 ～ 4 名、開発者あたり 0.5 ～ 1.5 名の QA 担当者、その他 1 ～ 2 名) の場合、このスプリントには 2 ～ 4 つのユーザー ストーリーがあるはずです。製品所有者と 30 分ほどかけて要件を明確にし、その後 30 分ほどかけてそれを最大 8 時間のタスクに分割します。 会議中にタスクを入力しないでください。 チームとして、良識ある人が理解するのに十分なタスクは何か、その責任者は誰か、それにどれくらいの時間がかかるかについて合意するだけです。「（テストを含む）所要時間」がスプリント内に収まるように同意します。
物事をタスクに分割するだけではない場合、他に何をしているのでしょうか? 確かに、振り返りには 30 ～ 60 分かかる場合がありますが、チームの調子が良くなると短くなるでしょう。
要約すると、人々の時間を無駄にするのをやめれば、会議への恐怖も少しは薄れるでしょう。さらに、チーム内の楽しさや仲間意識は、会議で話し合えるものではありません。一緒にランチに行ったり、冗談を言ったり、性格をより良く合わせるために人々を混ぜたり、口ひげを生やすコンテストをしたり...士気が高まると、人々は自然にスプリント計画会議をもっと気軽にするでしょう。
計画は、チームがたくさんの柔軟性を持っているスクラムの1つの領域です。あなたがあなたのチームのために機能する何かにヒットするまで、すべてのスプリントを試してみてください。
私が個人的に試した、あるいは他のチームから聞いたことがあるいくつかの成功したアイデア：
- チーム全体なしでユーザーストーリーの作成と優先順位付けを行います。製品の所有者および/またはスクラムマスターは、多くの忙しい仕事を扱うことができ、ちょうどチームがそれを微調整させることができます。
- あなたのバックログを単一のスプリントよりも大幅に長くします。それはそれを築くためにしばらく時間がかかることがありますが、あなたのバックログが十分に長い場合、計画会議は小さな調整や最近のビジネス開発を行うために減らされます。
- スプリントプランニングとは別の推定会議があります。会議が長すぎると考えると、それらを分割しない理由はありません。
- 特に計画を立てる。これは、1つか2つのチームメンバーが返却するのを待っている時間を無駄にする場合に便利です。
- 会議の途中でブレークし、誰もが1つか2つのユーザーストーリーをタスクして割り当ててから、報告して合意を得るために集まります。
- あなたの計画会議は、のについてののであることを確認してください。エンジニアは後者に非常に簡単に落ちる。必要に応じて、あなたがどのように議論している別のデザイン会議をセットアップします。
- あなたの物語を調査と実装に分離します。計画会議は、チームメンバーが彼らが取り組んでいることについてほとんど知らず、会議中にそれを理解しようとしているときに長すぎる。
たとえば、あなたのチームが経験がないというAPIと統合する必要があるとします。と一緒に。企画会議の間に見積もりとタスクを作成しようとするのではなく、APIを学ぶために1回の調査ストーリーを作成し、単純な「Hello World」アプリをしてチームに教えてください。 それから実際の作業を計画するために装備されています。 - 具体的な問題の会議中に追跡してください。 「計画は退屈だった」だけでなく、「不明な要件について話している時間をたくさん過ごし、誰も正しい答えを知っていないようです」のような細部のレベルのレベル。それから特定の解決策のためにあなたの遡及とブレインストームの具体的な問題について話し合う。ピースが解決しやすくなるまで問題を解決します。
私たちはスプリントの計画と遡及的に同時に開催され、ほとんど90分で行われていますが、私たちはより速いチームの1つです。 5~6時間かかる5スプリントごとに大規模な長期的な計画を立てます。もちろん、すべてのチームが異なりますが、あなたがすべてのスプリントを費やしているなら、たくさんの改善の余地がたくさんあります。
あなたの計画セッションは長すぎるような方法です！
私の経験に基づいて、スプリント企画会議は週2時間以内に予定されている（例えば、2週間のスプリントが最大で1/2日かかります）、成功したものよりも短くなるべきです（半数それ）。
あなたの特定のケースで：なぜあなたは仕事を推定しているのですか？計画中にストーリーのみを見積もるべきです。タスクは、固有のタスク所有者によって後で推定できます。
私のために働いた方法：
- PO によるスプリントへのクイックイントロ
- スプリント容量の推定
- ストーリーSprint をカバーするのに十分な推定値があるまで、ポーカー（ストーリーごとに5/10分でタイムボックス）
- チームによる公式コミットメント/予測
私の前の仕事では、各スプリントの最初の日全体の一日（私たちはそこにそれらの反復と呼びました）が取り上げられました：
- 遡及的な私たちは最後の日の午後にこれをし始めましたが、私たちはスプリントについての遡及を見つけてから、そのスプリントの仕事の最後の緩い端を縛る仕事に戻ることがよくありますそれで、私たちはそれを後退させる前に、仕事がすべて私たち全員であることを確認することをよりよく考え出した。また、スクラムプロセスのすべての会議のオーバーヘッドを統合するために論理的に見えました。他の日を計画して理想的な用語で費やすことができます。これは通常2時間かかりました。
- スプリントプランニングバックログは、マイルストーン計画会議（DevsとPOSの両方で一日中常駐する可能性がある）の間に推定され、開始前のPOSによって優先されていました。各スプリントの。私たちは、私たちが利用できる開発日（休日、vacaなど）を持っていたのを考え出し、私たちが山の上からすることができると思った仕事を把握し、すぐに（以前は私たちのBASによって吟味された）を確認しました。 MPMの間に単純な概要で手を差し伸べるよりも伴う作業が何を伴うもののより完全な感覚を得る。これは通常さらに2時間かかりました。
- タスクの計画。物語と受け入れ基準を知ることで、私たちは理想的な時間で推定された咬合サイズのタスクに各ストーリーを破った（1時間の費用があります。または障害物）。私たちのポイントスケールが較正された方法で、5は開発者スプリントであるので、1つは2つの開発者日まで何でも含めることができました。そのため、チームメンバーがスクラム板の進捗状況を表示できるようにするためには、実質的にすべてが分類されなければなりませんでした。これはさらに2時間のブロックであり、これと次のアイテムとの間のあきらめとの間にあります。
- aat概要私たちのPOSとBASはプログラマーではなく、コードしていませんでした。彼らが辞書のテンプレートの形で要件を提供し、その形でそれらを洗練することを規定する契約の後ろにあるPOS HID。基本的なコードが理解されていましたが、彼らの時間は純粋に分析と最終テスト（システムが存在することを要求されるので、彼らは彼らのマクロをセレンに記録することができました）でした。それで、それがそれが来たときに私たちのコードが受け入れ基準を満たすことを確認するために、私たちは「紙」の受け入れテストの行動をモデル化する私たち自身のAATを書く必要がありました。私たちは通常、私たちがユニットと統合テストに使用したのと同じNUnitフレームワークでこれをしました（私たちはフィットネスを試み、十分に速くそれを与えることができませんでした）。これは各スプリントの最初の日の残りの部分でした、そして2番目に続いた。
現在の仕事では、まだスクラムプロセスを採用していますが、チーム全体のマイルストーンの計画を立てていませんでした、そして、私たちが取り組んでいることは厳密な受け入れ基準を持っていません。だから、私たちのスプリントの計画は、各ストーリーが何を伴うものと私たちがコールするのか、そしてそれがトップXの理想的な勤務時間を上から見たことのためのコミットメントです。私たちはそれを逃がしています - 少なくとも - 私たちは社内のチームと私たち一人一人が個人的に私たちのソフトウェアのエンドユーザーと個人的に働き、要件と設計ソリューションを収集します。それでも、スプリント計画は月曜日の毎週朝のものであり、午後は火曜日に本格的に開発を始めることができるような個人的な障害物をクリアしています。
他のコメント/答えを対比するのではなく、それを考えてはいけないと言っていてはいけません、あなたが使うよりももう少し興味深いスプリントの計画と遡及に取り組む方法があります。
あなたの懸念の取り組み：
-
会議は長い - タイムボックスです。各会議、それはそれに遡及的、スプリントの計画、タスクの内訳などであり、明確な目的と議論のトピックを持つべきであり、そして設定された時間だけできる限り制限されるべきです。これらの会議をトピックと回転させて時間目標を満たすために、スクラム修士の仕事です。
-
会議は単調です - それのいくつかがあるでしょう。あなたは一度に一度に一つずつ、噛み付くサイズのチャンクで働いているので、同じことをやり戻しているでしょう。チームを集中させ、会議の目的を達成することに向けた運転を守ることは役に立ちます。
私が聞いている他のものは、あなたのスプリント計画会議がそれほど多くを達成しようとしているかもしれません。私の最後の会社では、ストーリー推定は「マイルストーン計画会」で行われました。これらの会議では、推定していなかったバックログに蓄積したものすべてがポイントで推定されました。物語の見積もりをしている場合、その後時間単位でタスク推定を行っても、同時にそれらの両方をしたくない（たぶん同じ日に）。
-
点で物語を推定すると、時間内のタスクは冗長に見えます
あなたの物語がすべて1日以下にかかる場合は冗長ですが、すべての点スケールが等しく校正されているわけではありません。私の最後の仕事で、5は2つの開発者週間でした（冒頭では推定する叙事詩がたくさんあるため）、これは線形のスケールで2つの開発者日までの意味を表しました。そのような規模のように、ほぼすべてがタスクに分類されるべきです。私の新しい会社では、ポイントは開発者の半分に近いので、1つか2つか2つでさえもそれ自身のタスクであり、3-8はチームをタスクに分割することに関して漠然としています。
人々がより長くなっているように、人々がより長く焦点を当てているようにするのが長い悪循環があります。符号化時にいるのと同じように、休憩を取ってください。 30分ごとに、足、再編成などを伸ばすのに5分かかります。時間毎に10分、それ以上の会議の時間があまりにもずっとしすぎることはできません。あなたの人は空腹になったり、より多くのコーヒーを飲んでいるかもしれません、それともバスルームの休憩などを否定しません。あなたがそれらを吸い込むようにするならば、あなたは彼らの心がさまようのを見つけるでしょう。それを超えて、以前に述べたように、議論を短く、甘く、そしてポイントに保ちます。
スプリント計画会議には2つの部分があります。
- チームが何をするかを決める
- チームがどのようにするかを決めます。
最初の部分は比較的簡単です - チームが彼らが取ることができると感じるストーリーポイントの数に基づいて、その多くのユーザーストーリーを優先順に完了させることを約束します。完了しました。
第2部は、開発者が実際に享受するべきですか - 物語の詳細と解決策の設計です。タスクはそれから抜け出します。それで、製品の所有者、または彼が提供した中小企業は、選択された物語を説明しています。その後、開発者がそれを取得したいのですが、デザインディスカッションをリードしてください。ホワイトボードを使用してください。アイデアを跳ね返る。楽しんでください。
それは本当にそれです。デザイン会議が楽しんでいない場合は、普通のものが間違っているだけです。
私はこれが古い質問であることを知っていますが、私は新しい答えを持っています。 ：p
会議を分割します。
スプリント計画会議を3つの別のミニミーティングに分割します
- バックロググルーミング
- ストーリー選択
- タスクの内訳
私たちは毎日のスクラムの直後にそれぞれをします - 毎日が行われるとすぐに、私たちは計画活動に正しくロールしています、そして私たちはその日の残りの部分から（定期的に計画された）集会から解放されています。
だからええ、私たちの計画を滝しました：-O
各セッションに何を伴うものについてもっと詳しく説明しますが、私たちがこれに到着した方法を説明しましょう。
私たちは、自分のように、本当に恐ろしいスプリント計画会議に問題がありました。私たちはすべての正しい要素を持っていましたが、すべてが永遠にかかってきただけで、実際には精神的かつ感情的に排出されました。
それから私はこの考えを読んだ後、このビジネスインサイダー毎日の毎日の5分の記事の記事は、会議を短いセッションに分割し、毎日の始めにそれらをすることについて。
私は遡及的にチームと一緒にいました。一部のチームメンバーはすぐに好きだった、他の人は少し不安を抱いていましたが、私たちのインターンは彼が何らかの研究を言及していました。 The Pomodoro Technical とそれについて始めました、そしてそれは本当にアイデアの牽引力を助けました。
だから私たちはそれを試すことにしました。
私たちは2時間のミーティングを3つの25分のセッションに壊しました。 （はい、それはあいまいな数学ですが、誰もが私たちの会議が長すぎると感じ、時間を節約したらしばしばやりたいだけでした）。
働いた！
私たちは2つの別々のプロジェクトで約6週間それをやっています（合計6つの2週間のスプリント）、それは違いの世界になりました。
もっと生産的です。
私たちは時間を節約します。
より良い出力が得られます。
そして私達はもはや私達の計画会議を恐れていません。
と正直なところ、私たちの25分のタイムボックスはかなり緩んでいます - 私たちのグルーミングセッションのいくつかで5~10分、そして何度も長く、そして私たちが新しいストーリーを識別することやしなければならないときのようにネゴシエーション中にストーリーを折り返して再推定します。全体的に、それは通常、シーバン全体のために1.5時間以下に平均化され、それがそれがうまく機能する理由だと思います。
詳細へ.....
バックロググルーミング
かなりシンプル - 最優先ストーリーを見直し、彼らが伴うものについて話し、私たちの推定値が良いことを確認してください。
必要に応じて物語を再推定します。何らかの前に推定したとおり、類似した物語が実際に取ったものを実現した後、私たちは再推定に同意するかもしれません。 （単位レスストーリーポイント/ a>ところで、そしてwer タスクを見積もりません）。
また、POが彼が感じる新しい物語を優先した新しいストーリーを追加した場合、これはそれらを推定する時です。
翌日までストーリーの選択をしないので、このプロセスは次の反復で行われることが最も重要なのかについて最終的な判断をするためにPOに少し余分な時間を与えます - そしてこれは非常に役立ちました。
この会議は、何人かのPOと他の人と長い間短く走る傾向があります。 （個人的には、私はそれがあなたのPOをやっているのかの素晴らしい匂いの指標だと思います）
ストーリー選択
chris voss ON、交渉する時期です。
この会議では、最優先ストーリーを取り、 dod それぞれのために。私たちはすべてのスプリント目標に同意することができるまで、それぞれが必要に応じてストーリーを分割し、結合するものを交渉します。
タスク
大丈夫だから私は最初に言っています、仕事は私たちの古い1日の会議での計画の私の のお気に入りの部分でした。
私たちはこれを越えて私たちのストライドを打つことは決してないだろう。 私たちは会議の終わりにタスクを節約しようとしました - しかし、私たちはそれから排水されただけで、それは本当に生産的でした。 私たちは交渉中に私たちのDODと同時にタスクを定義しましたが、気を散らすと面倒すぎることがわかりました - 私たちはすべての物語を選択する前に自分自身を燃やすでしょう。また、推定、交渉、ストーリーの選択、およびタスクGeneratiの間に焦点を当てたり考察したりすることは本当に困難でした。
オン。私たちは苦労して吸い込んだ、そしてそれは私たちの会議を恐ろしいものにしました。今、 は一日にドッドを定義し、次にタスクをしていないので、私たちは燃やしていません、私たちは常に正しいMindStateにあり、それは私たちに与えます物語の上にマリネを解除し、私たちが始める前にすべてのタスクを実際に考え、理解するための一日。
これだけでは、トータルゲームチェンジャーです。
それをまとめて置く。
だから、私たちのスプリント式典のスケジュールは今のように見えるものです。
- 月曜日 - 毎日のスクラム - >スプリントレビュー
- 火曜日 - 毎日のスクラム - >バックロググルーミング
- 水曜日 - 毎日のスクラム - >ストーリー選択
- 木曜日 - 毎日のスクラム - >タスク
- 金曜日 - 毎日のスクラム - >遡及
それは私たちにとって本当にうまくいった。 あなたがそれを撃ったならば、私はあなたが思うものを聞いてほしいのです。
前のスプリントについて話し合う1時間の会議で毎週スプリントを持っています。これは何をしてから来週の計画に進みます。 1時間以内に。
これはもちろん私たちはスクラムを厳密に浪費するだけであまりにも多くの時間を無駄にするだけであることがわかりました。それは、要求者がユーザーストーリーを作成するときに、ほとんどのストーリーが私たちのチームメンバーとすでに議論されているからです。
あなたのチームが会議を訓練するならば、あなたはおそらくスクラムの「規則」のいくつかを手放すべきだと言っています。
この質問は包括的に回答されていますが、それを仕事をするために必要なものだけが必要です。
チームに力を与える - すなわち、 が最も重要であることを考えてください。
