スプリントプランニングの進め方とスプリントバックログの作成方法

【目次】
・はじめに
・スプリントプランニングのポイント
　- 確実に終わる計画を立てる
　- プロダクトバックログの意図を理解する
　- スプリントの完了条件を決める
・スプリントプランニングの進め方
　- プランニングの準備
　- 目標とスコープ設定
　- スプリントバックログの作成
・スプリントゼロ

はじめに

スクラムでは定められた期間をセットとして、開発作業を進めます。
このセットをスプリントと呼び、このスプリントの進め方を計画するのがスプリントプランニングです。
ここではスプリントプランニングの進め方と、スプリントバックログを作成するまでの流れについて解説します。

ちなみにスプリントはプロダクトバックログと密接に関連します。
プロダクトバックログについては、別記事「プロダクトバックログ」を参考にしてください。

スプリントプランニングのポイント

スクラムは実装する機能をプロダクトバックログで管理し、優先度の高いアイテムから順次、スプリントに渡して開発していきます。
プロダクトバックログの機能を実装するための作業内容を具体化し、担当者を割り当て、何を作るのか計画を立てます。

スプリントプランニングでは、以下の点に考慮して進めます。

確実に終わる計画を立てる

スクラムではスプリントごとに作業を完結させることが重要です。
未完了分を次のスプリントに回すことは避けます。

そのためには、各タスクの作業量を正しく見積もる必要があります。
開発者に割り当てるタスクの粒度が荒く、1タスクの完了に数日かかるようでは作業の進み具合によってブレ幅が広がります。
大きくても１タスクが１日以内に収まるようタスク分解します。

もし予定より早くタスクが完了したら、次のスプリントで予定していた作業を前倒しすれば良いです。
ギリギリの期間を狙って成果物が完成しないより、少し余裕をもって設定することが望ましいです。

プロダクトバックログの意図を理解する

担当者が作業内容を理解できるように、プロダクトオーナーと開発チームが十分に対話します。
作業内容を聞くだけでなく背景や目的について理解することで、期待された価値ある機能の提供につながります。
開発チームは指示待ちワーカーでなく、価値ある機能を提供するために知恵を出す必要があるためです。

「わからなくなったら開発途中で聞けばよい」という考えは捨て、できるだけスプリントプランニングで確認を取ります。
スプリントが始まってから個別にプロダクトオーナーを捕まえて確認するのは時間を要することが多いためです。
タスクの規模見積もりにも影響する可能性もあります。

スプリントの完了条件を決める

スプリントの最後にスプリントレビューを行い、実装完了しているか確認します。
このレビュー時に何ができれば完了なのか明確になっていないと、ゴールが不明瞭な状態で実装確認することになります。
これでは開発チームも何を目指して作業すればよいかわからなくなります。

完了条件を計画段階で決めることで、メンバの目的意識を統一することができます。
もし完了条件を決めずに作業を進めた場合、最後になって想定外が発生するでしょう。

スプリントプランニングの進め方

プランニングの準備

プロダクトバックログに着手できる状態を「準備完了（Ready）」と呼びます。
この準備とは、対象のPBI（プロダクトバックログアイテム）が次の状態になっていることを指します。

スプリントの期間で完成させられる規模であること
実現したい機能要件が明確になっていること
PBIの見積もりがされていること
受入条件が定義されていること

上記の状態がそろっていなければスプリントを開始することができません。
無理やり進めると仕様確認やレビューで揉める原因となり、結果として生産性が大きく下がります。

準備完了しない事態となるのは、次の２パターンに分かれます。

プロダクトオーナーが役割を理解していない

スクラムに慣れていないプロダクトオーナーの場合、プロダクトバックログの意味や進め方を理解していない場合があります。
そのような場合は、スクラムマスターがプロダクトオーナーを指導したり、作業支援を行います。

プロダクトバックログの検討が進んでいない

プロダクトオーナーが忙しくてプロダクトバックログの精査に着手できなかったり、IT知識不足により検討不十分になる場合があります。
その場合、開発チームがプロダクトバックログ作成の支援に入ることがあります。
スプリントの中で、次のスプリントに向けたプロダクトバックログの検討作業という枠を設けます。
この作業のことをリファインメントと呼びます。
このリファインメントに開発チームのパワーが多く割かれるのは本末転倒なので、全体作業の10%以下に抑えます。

ちなみにプロダクトオーナーが別作業などでスクラムチームとしての活動ができない状態の場合は、プロダクトオーナーの交代も含めてスクラムマスターが調整します。

目標とスコープ設定

スプリントの中で達成する目標をスプリントゴールと呼びます。
スプリントプランニングでは目標を設定し、目標達成を確認するための完了条件を定義します。

スプリントゴールは、スプリント内で完了できるものを設定します。
そのためには１スプリントの中で対応できる規模（ベロシティと呼ぶ）と、プロダクトバックログの規模を比較しながら検討します。
このベロシティは過去のスプリントの実績から算出します。

この作業はプロダクトオーナーと開発チームが連携して決定します。
そのためプロダクトオーナーはスプリントプランニングに必ず参加する必要があります。
プロダクトオーナーを代理に任せたり、スプリントプランニングを開発チームにお任せする状態はNGです。

スプリントバックログの作成

目標とスコープ設定を行ったら、プロダクトバックログを完成させるためのタスクを洗い出します。
ここで出てきたタスクをスプリントバックログとして管理します。
スプリントバックログでは作業詳細ごとにアイテムを作成し、それらの規模を設定します。
この規模は細かい方がよく、大きくても1日以内の作業まで分解します。

ちなみにタスクの規模が荒い状態でスプリントを開始するのは避けます。
スプリントプランニングの時間を延長してでも詳細化する必要があります。

スプリントプランニングは計画と設計を足したものに近いです。
設計が中途半端な状態で製造すると不具合につながるのと同様に、スプリントプランニングを中途半端にすると、開発もうまくいきません。

タスク整理したら、担当者を割り当てます。
もしスクラムに慣れていないメンバがいたら、その人には余裕ある規模のタスク割り当てをします。
スクラムに慣れていないと、思っている以上に作業は進みません。
慣れた人の作業ペースに合わせても遅れはでるので、スプリントが終わらない事態を避けるための調整を行います。