エンジニアリングチーム向けスプリントプランニング議題テンプレート
スプリントが過負荷になる理由
スプリントプランニングには、テンプレートでは防げない構造的な失敗がある。それは、チームがキャパシティを確認する前にスプリントバックログを選んでしまうことだ。その結果、ホワイトボード上では達成可能に見えたスプリントが、水曜日には崩壊する。エンジニア2名が週の半分不在で、チケット1件がスコープ3倍になり、さらに3件にはプラットフォームチームが書き直し中のサービスへの未明示の依存関係があった——という状況に陥るのだ。
解決策はシンプルで、しかもほぼ誰もやっていない。作業にコミットする前に、キャパシティにコミットすることだ。以下のテンプレートは、まさにその理由からキャパシティレビューを冒頭に置いている。
議題（コピー&ペーストで使用可能）
所要時間： 2週間スプリントの場合は2時間、1週間スプリントの場合は1時間
形式： ファシリテーター進行、バックログをチーム全員に共有した状態で実施
セクション1 — スプリントゴール（10分）
- 一文で表す：外部から見て、成功したスプリントとはどのような状態か？
- ゴールはスプリント終了時に達成できたかどうかをチームの誰もが判断できる具体性を持つこと
- 「認証リファクタとビリングページを完了する」のようにチケットの羅列になっているゴールは却下する——それはバックログであり、ゴールではない
セクション2 — キャパシティレビュー（15分）
- チームメンバー全員を名前で列挙する
- 各メンバーについて：予定しているPTO、オンコールローテーション、定例会議、既知の外部コミットメントを確認する
- キャパシティはヘッドカウントではなく、利用可能なストーリーポイントまたは日数で表す
- この数値が上限となる。それを超える作業を選択しないこと
セクション3 — バックログ選択（45分）
- 精査済みバックログから優先度の高いアイテムを順に確認する
- 各候補について：スプリント開始に必要な情報が揃っているか、それとも着手前に回答が必要な未解決の質問があるか確認する。未解決の質問はリファインメントキューに入れ、スプリントには含めない
- キャパシティの80%に達した時点で選択を止める。残りの20%はスピルオーバーや計画外の作業の吸収に充てる
セクション4 — 受け入れ基準（20分）
- 選択した各アイテムについて：完了とみなす基準を明示する
- 60秒以内に基準を言語化できない場合、そのチケットは十分にリファインされていない——バックログに戻す
- 「後で追加する」に頼らず、今この場で、この部屋でチケットに記載する
セクション5 — リスクと依存関係（15分）
- スプリントゴールの達成を妨げる可能性のある、チームがコントロールできない要因は何か？
- 依存先のオーナーを明示する。スプリント中盤より今の方が解決しやすい
- 未解決の依存関係には、チームからトラッキング担当者を一人指名する
クロージング（15分）
- 選択した作業を踏まえ、スプリントゴールが引き続き有効であることを確認する
- スプリント振り返りのノート担当者を決めるか、自動レポート設定を確認する
- 次回プランニングの日程を確認する
多くのスプリントプランニングテンプレートが見落としていること
人気のあるスプリントプランニングテンプレートの多くは、バックログのグルーミングとDone（完了）の定義に焦点を当てている。どちらも重要だ。しかしどちらも、スプリント失敗の最大の原因——稼働状況を確認しないまま作業を選択すること——には対処していない。
フル稼働状態の5名チームは、2週間スプリントでおよそ200ストーリーポイントをこなせる。しかし同じ5名でも、エンジニア2名がPTO中、1名がオンコールローテーション中、1名が3日間のオフサイト参加中であれば、せいぜい110ポイントが限界だ。もし2つ目のスプリントで180ポイントを選択してしまえば、すでに失敗している。過剰コミットは選択の段階で起きるのであり、キャパシティの確認はその前に行わなければならない。
2つ目のギャップは受け入れ基準にある。チームはプランニングを速く進め、後で基準を書こうとする。しかし後になって同じ粒度で書けることはほぼない。その場で精確な基準を書けた人も、翌日には記憶を頼りにより曖昧なものを書くか、まったく書かない。スプリント中盤に「完了」の定義をめぐる議論が起きるとしたら、それはほぼ必ず、プランニングで受け入れ基準をスキップしたことに起因する。
これらのギャップが重なるコスト——過負荷スプリント、スプリント中盤での発覚、再定義の繰り返し——を合計すると明確になる：会議の税金。
スプリントプランニングのメモが難しい理由
スプリントプランニングは、ほぼどの定例会議よりも多くの情報を生み出す。スプリントゴール、キャパシティ数値、アイテムごとの選択理由、チケットごとの受け入れ基準、依存関係のオーナー、リスク項目——これらすべてを、3日後に誰かが「なぜそのアイテムを外したの？」と聞いてきたときに役立つ形で記録することが求められる。
Pavleurは、コール終了時にスプリントプランニングレポートを自動生成する。スプリントゴール、選択バックログと選択理由、会議中に述べられた受け入れ基準、指名された依存関係オーナーを記録する。誰かがバックログや稼働状況のスプレッドシートを画面共有していた場合、その画面は議論の記録とともにレポートに含まれる——OtterやFirefliesのような音声のみのツールが見逃してしまうコンテキストだ。遅れて参加した人も、スプリント中盤に決定内容を確認したい人も、完全な記録を参照できる。これが音声のみのツールとどう異なるかについては：Pavleurと他ツールの比較。
スプリント中盤の計画変更への対応
スプリント計画はコミットメントであり、契約ではない。本番インシデント、複数チケットをブロックする重大な依存関係、経営からの優先度シフトなど、スプリント中盤に計画を根本から覆す事態が発生した場合、正しい対応は再プランニングの場を短時間で設けることであり、暗黙のスコープ削減ではない。再プランニングは20分あれば十分で、実態を反映した更新済みスプリントゴールが生まれる。代わりに何も書き残さず非公式に調整した場合、振り返りが困難になり、ベロシティの数値も意味をなさなくなる。
明示的な再プランニングを習慣にしよう。同じ構成を使う：更新されたキャパシティ、見直された選択、再定義されたゴール。それが防ぐ混乱に比べれば、はるかに短い時間で済む。