プロジェクト実務
スプリントプランニングで何を決めればいいか迷うときのチェックリスト:スプリントゴール・バックログ選定・キャパシティ予測の手順
スプリントプランニングで決める7つのこと(チェックリスト)
スプリントプランニングが終わった時点で、次の7つが確定しているかを確認する。1つでも欠けていれば、そのスプリントは走り出した後に迷子になりやすい。
1. Why: プロダクトオーナーが「今回のスプリントでプロダクトの価値と有用性をどう高めるか」を提案したか
2. Why: その提案を受けて、スクラムチーム全体でスプリントゴールを1つに定めたか
3. What: 開発者がプロダクトオーナーとの対話を通じて、今回のスプリントに入れるプロダクトバックログ項目を選んだか(プロダクトオーナーが一方的に割り振っていないか)
4. How: 選んだ項目ごとに、完了の定義を満たすインクリメントを作るための作業を開発者が計画したか(多くは1日以内の単位に分割されているか)
5. 予測の根拠: 過去の実績・今後のキャパシティ・完了の定義の3つを材料に、開発者自身が予測の確度を判断したか
6. 締め: スプリントゴールが、プランニングの終了時点までに確定しているか(「持ち越して後で決める」になっていないか)
7. 時間枠: 1か月のスプリントなら最大8時間、短いスプリントではその比率で短く終えられているか
以下、この7項目それぞれの根拠と、現場でズレやすい点を解説する。出典はすべてScrum Guide(2020年版、scrumguides.org、2026年10月19日取得)。
土台:スプリントプランニングが生み出す「スプリントバックログ」
スプリントプランニングは、スプリントで行う作業を洗い出すことでスプリントを開始させるイベントと定義されている。できあがる計画は、スクラムマスターを含むスクラムチーム全体の協働作業によって作られる。プロダクトオーナーは、重要なプロダクトバックログ項目について話し合えるよう準備しておく役割を担う。
このプランニングの成果物が「スプリントバックログ」である。スプリントバックログは、スプリントゴール(Why)、今回のスプリントに選んだプロダクトバックログ項目(What)、そしてインクリメントを届けるための計画(How)の3つで構成される。チェックリストの7項目は、この3要素をそのまま分解したものにすぎない。
Why:スプリントゴールは「提案」から「合意」へ
スプリントプランニングには3つのトピックがあり、1つ目のトピック(Why)では、プロダクトオーナーが「このスプリントでプロダクトの価値と有用性をどう増やせるか」を提案する。そのうえでスクラムチーム全体が話し合い、スプリントゴールを定める。
ここで重要なのは、スプリントゴールを決めるのはプロダクトオーナー単独ではなく、スクラムチーム全体という点である。提案はプロダクトオーナーから出るが、合意はチーム全体で取る。そしてスプリントゴールは、プランニングが終わるまでに確定していなければならないと定められている。ゴールが曖昧のままプランニングを終えると、後続のデイリースクラムが検査する対象そのものが無くなる。
What:バックログ項目を選ぶのは開発者
2つ目のトピック(What)では、開発者がプロダクトオーナーとの対話を通じて、プロダクトバックログから今回のスプリントに含める項目を選ぶ。選ぶ主体は開発者であり、プロダクトオーナーが優先順位を示すことと、開発者が「今回のスプリントに入れられる範囲」を決めることは、別の役割として分かれている。
この選択がその場で難航するチームの多くは、プランニングに持ち込む項目がまだ粗いまま残っている。1つのスプリントで完了できる程度まで分割・詳細化された項目は、プランニングで選択できる「レディ」な状態にあるとされ、この透明性は通常、スプリントの合間に行うプロダクトバックログのリファインメントの結果として得られる。リファインメントを済ませていない項目ほど、プランニングの場で初めて中身を精査することになり、Whatの決定に時間がかかる。
How:作業計画とキャパシティ予測
3つ目のトピック(How)では、選んだプロダクトバックログ項目それぞれについて、完了の定義を満たすインクリメントを作るために必要な作業を開発者が計画する。この作業は、しばしばプロダクトバックログ項目を1日以内の単位の作業に分割する形で行われる。どう分割するかは開発者の裁量であり、他の誰かが「どうやって価値のインクリメントに変換するか」を指示する立場にはない。
予測の確度についても明確な記述がある。開発者が自分たちの過去の実績・今後のキャパシティ・完了の定義について知っているほど、スプリントの予測に対する自信は高まるとされている。つまりキャパシティ予測は、特定の計算式ではなく、この3つの材料をチームがどれだけ持っているかに依存する。
一方で、スクラムガイドは予測そのものの限界も明記している。バーンダウン・バーンアップ・累積フロー図といった進捗予測の手法は有用だが、経験主義(Empiricism)の重要性に代わるものではなく、複雑な環境では「これから何が起きるか」は分からない。将来の意思決定に使えるのは、すでに起きたことだけだとされている。キャパシティ予測は「当てる」ための計算ではなく、経験に基づいて確度を上げるための材料という位置づけになる。
タイムボックス:1か月スプリントで最大8時間
スプリントプランニングのタイムボックスは、1か月のスプリントに対して最大8時間と定められている。スプリントがそれより短い場合、イベントは通常より短くなるが、具体的な時間数までは定められていない。
実務では、この8時間を4週間あたりの上限として、スプリントの長さに比例させて割り当てる考え方が使われる。
4週間の行だけがスクラムガイドに明記された数値で、それ以外は上限からの比例計算による目安である。実際にかかる時間は、プロダクトバックログ項目のリファインメントがどこまで済んでいるかで変わる。
タイムボックス:1か月スプリントで最大8時間
| スプリントの長さ | タイムボックスの目安 |
|---|---|
| 1週間 | 約2時間 |
| 2週間 | 約4時間 |
| 3週間 | 約6時間 |
| 4週間(1か月) | 最大8時間 |
よくあるズレ:プランニングが機能しなくなるパターン
よくあるズレ:プランニングが機能しなくなるパターン
| パターン | 何が起きているか | ガイドとのズレ |
|---|---|---|
| プロダクトオーナーが項目を割り振る | プロダクトオーナーが「今回はこれをやってください」と一方的に項目を指定する | Whatを決めるのは開発者であり、対話を通じて選ぶという役割分担から外れる |
| ゴールを決めずに項目だけ合意する | バックログ項目の一覧には合意したが、「なぜこのスプリントをやるのか」の一文がない | スプリントゴールはプランニング終了までに確定が必要という規定から外れる |
| リファインメント無しで大きい項目を持ち込む | 粗いままの項目をその場で初めて見積もる | レディな状態は通常リファインメントの結果として得られるという位置づけとズレ、Howの計画が粗くなる |
| タイムボックスを大きく超える、または数分で終わらせる | 8時間(1か月換算)の目安を大幅に超えて延長する、または形だけで終える | 時間をかけすぎるとHowの検討が粗くなる一方、短すぎるとWhy/Whatの合意が形だけで終わる |
プランニングの前後をつなぐ
スプリントプランニングは単独のイベントではなく、前後の活動とつながっている。プランニングに入る前には、プロダクトバックログのリファインメントによって項目がレディな状態まで分割・詳細化されている必要がある。リファインメントを飛ばすほど、プランニングの場でのWhat・Howの検討が重くなる。
プランニングが終わった後は、確定したスプリントゴールとスプリントバックログが、デイリースクラム・スプリントレビュー・レトロスペクティブで検査する対象になる。デイリースクラムはスプリントバックログへの進捗を、スプリントレビューはインクリメントを、レトロスペクティブはこの一連の進め方自体を検査する。プランニングの時点でWhy・What・Howのいずれかが曖昧だと、後続のイベントは検査すべき対象を失う。
冒頭の7項目は、この前後のつながりを含めてプランニングの場で確認するための実務チェックリストである。
出典・参考
公開情報および各機関の一次情報をもとに、PMアンカー編集部が作成・更新しています。事実関係は出典を明記し、内容は定期的に見直しています。