プラクティス名（別名）
スプリントプランニング （スプリント計画、計画ゲーム）
プラクティスの目的・狙い
- スプリントの目的とゴールの明確化
- タスクの洗い出しと計画
- 作業量の見積もり
どんな時に使うか
- スクラムでは必須（各スプリントの冒頭で実施する）
- スプリント作業が場当たり的に進んだり、作業量が多くて終わらない、といった事態を防止したい時
実施手順
- POが今回のスプリントでしたいこととその理由を説明し、スプリントゴールを提案する
- プロダクトバックログの中から今回対象とするアイテム（PBI）をいくつか選ぶ
- PBIを実現するために必要なタスクを全て洗い出し、スプリントバックログに落とし込む
- 個々のタスクは1日以内で完了する粒度まで詳細化し、作業量を見積もる
上記1.で何故（Why）を、2.で何（What）を、3～4.でどのように（How）を突き詰める。
計画段階でチームのキャパシティを超えているようであれば、持続可能なペースとは言えないので、スプリントゴールとPBIの選択を見直す。
アレンジ例
- 時間短縮のためDEVをペアに分け、分担してタスク分解し、それを持ち寄る
- タスク洗い出し後、「完成の定義」を確認し、作業漏れがないか確認する
アンチパターン
- タスク粒度が大きすぎて、各タスクを進捗率で管理しようとする
（→進捗はシンプルにタスクの完了/未完了だけで管理すべき）
参考情報
こぼれ話（私的コメント）
タスクを全て消化したハズなのに、いざリリースしようとすると、じゃあこれもやっておかないとね、と隠れタスクが顔を出すことがあります。これはUndoneタスクと呼ばれるもので、計画時のタスクの洗い出しが不十分だったか、完成の定義が不十分であることを意味します。またそもそもPBIを消化できたかどうかで意見が分かれる場合は受け入れ条件（AC）が不明確だった可能性があります。いずれにせよ最初から完璧な計画を立てることは難しいので、スプリントを重ねる中で精度を高めていく必要がありそうです。