「スプリントプランニング」のやり方を自信を持って説明できる人は少ないと思います。
チーム内でもプランニングの正解が知りたいって言われるんですよね……
とも坊目的をしっかりと理解することで、その不安も晴れると思うよ！
スプリントプランニングの基本知識から失敗例やノウハウを解説するね
・スクラムイベントにおける「スプリントプランニング」とは何かを理解できる
・スプリントプランニングの基本的なやり方がわかる
・失敗例やノウハウを知ることができ、より効果的なスプリントプランニングが実施できるようになる
スプリントのスケジュールでいうと以下の赤枠部分です。
スクラムイベント全体像がわからないからは、先に以下の記事をご確認ください。
PBL：プロダクトバックログ
PBI：プロダクトバックログアイテム
PO：プロダクトオーナー
SM：スクラムマスター
DoD：完成の定義
AC：受け入れ基準（Acceptance Criteria）
スプリントプランニングとは？
スプリントプランニングとは、スプリントのゴールを話し合い、そのゴールを達成するために必要な作業を計画するイベントです。
5つのスクラムイベントのうち、スプリントの一番はじめに実施します。
スプリントプランニングでは、これから実施するスプリントでユーザーにどんな価値を提供するか話し合い、それを実現するためのプロダクトバックログアイテムを決定し、どのように進めるか、どのくらい時間がかかるかを見積ります。
目的・メリット
[目的]
スプリントプランニングを通して、スプリントゴールや開発スコープ、プロダクトバックログアイテムの作業内容の認識を合わせることが目的です。
[メリット]
スプリントプランニングを実施することで得られる具体的なメリットは以下です。
・スプリントゴールを明確にすることで、スプリントの目的や作業に集中できる
・実施するPBIに関して、その場でPOに不明点を確認できるため、後々の認識齟齬が少なく済む
・PBIの実現可能性や実装方法に対して開発者の間で認識合わせをすることができる
（見積り精度が向上する）
とも坊スクラムチーム全員でスプリントゴールや実施するプロダクトバックログ アイテムの実装方法を検討する大切な時間だよ！
基本ルール
[タイムボックス]
以下の時間を目安に設定する。
・1週間スプリントの場合：2時間
・2週間スプリントの場合：4時間
※スクラムガイドでは、1ヶ月スプリントで最大8時間とされています。
[参加者/発言権]
※アドバイザーとして、実行タスクに精通したステークホルダーをを招待するもの可能です。
※スクラムマスターは、プランニングが正しく運営されるようにファシリーテートは可能です。
[やること]
プロダクトオーナー
・今回のスプリントで達成したいゴール(スプリントゴール)とその理由を開発者に宣言する
・プロダクトバックログアイテムの詳細説明及び受け入れ基準（AC）を説明する
・チームのベロシティと見積り結果から、スプリントの開発スコープを開発者と合意する
・スプリントゴールを達成するために、実施したいプロダクトバックログアイテムを提案する
・プロダクトバックログアイテムに対する開発者からの質問に回答する
・必要に応じてプロダクトバックログアイテムを見積りがしやすいように細分化する
・プロダクトバックログアイテムの見積りを開発者に依頼する
・開発者から見積根拠を確認し、不明点があれば確認する
開発者
・開発者全員でプロダクトバックログアイテムのストーリーポイントを見積る
・スプリントゴール達成がプロダクトビジョンやユーザーへの価値に繋がるか確認する
・プロダクトバックログアイテムの説明で不明点があればプロダクトオーナーに質問する
・PBIを実施するために必要なスプリントバックログアイテムを洗い出す
・実施対象のプロダクトバックログアイテムがスプリント内で完了可能か見積る
・チームのベロシティと見積り結果から、スプリントの開発スコープをプロダクトオーナーと合意する
・スプリントゴールとその実施理由が適切か確認する
・1つのプロダクトバックログアイテムが1日以上かかるボリュームの場合は細分化を依頼する
・見積り根拠をプロダクトオーナーに説明する
スクラムマスター
・スクラムチームにスプリントプランニングの目的を理解してもらう
・スプリントプランニングがスムーズに進むようにファシリテートする
・POがチームのキャパシティを超えた依頼を強行しようとしている場合は、代替案検討やステークホルダーへの調整を促す
[作成物]
・スプリントバックログ
スプリントバックログ = スプリントゴール + 実施対象のPBI からなります。
スプリントバックログに関しては、以下の記事で解説しています。
スプリントプランニングのやり方
[基本的な流れ]
以下の3部構成で進める流れを頭に入れておくと、スムーズに進行できると思います。
第1部(What)：スプリントゴールと開発スコープの説明
1. プロダクトオーナーが今回のスプリントゴールを宣言する
2. プロダクトオーナーが実施したいPBIの内容と受け入れ条件を説明する
3. PBIの説明を受けて、開発者が不明点を質問する
4. 開発者全員でPBIに対してストーリーポイントを見積る
5. 過去ベロシティとポイントの見積結果から、開発スコープを仮決定する
第2部(How)：スプリントバックログアイテムの洗い出し
6. 各PBIを実施するためのスプリントバックログアイテムを洗い出す
7. SBIの粒度が大きい場合は4時間以内に収まるように分割する
8. スプリントバックログアイテムを時間で見積る
第3部(Agreement)：スプリントゴールと開発スコープの合意
9. すべてのPBIを完了するために必要な時間を算出する
10. スクラムイベントの参加時間を算出する
11. PBI実施時間 + スクラムイベント参加時間 < スプリント稼働時間になるか確認する
12. キャパシティ内に収まるように開発スコープを調整する
13. プロダクトオーナーと開発者でスプリントゴールと開発スコープを合意し、スプリントを開始する
進め方のイメージ・具体例
慣れるまではスクラムマスターがファシリテートしましょう。
スプリントプランニングの流れがわかってきたら、POがファシリテートを担当するのがおすすめです。
（POからのインプットが多いため。）
スクラムマスタースプリント1のスプリントプランニングをはじめます。
はじめての人もいるので、スプリントプランニングの目的を簡単に説明させていただきます。
スプリントプランニングの目的を共有
（全員に目的が浸透してきたらスキップしてもOKです）
スクラムマスターはじめにプロダクトオーナーから、今回のスプリントゴールの共有をお願いします。
プロダクトオーナースプリント1のスプリントゴールは、
「ユーザーが勤怠登録システムに社員番号でログインできるようにする」です。
プロダクトオーナー初回のスプリントでは、開発環境の構築に時間がかかると思います。
ですが、ステークホルダーがシステムのイメージを掴めるように、実際に動かせるものを開発したいです。
なので、今回のスプリントでは、勤怠登録システムのTop画面から社員番号でログインできるところまでゴールとしたいです。
「ユーザーに××の価値を提供するために、△△を実現する」というフォーマットに沿って
宣言することが多いですが、スプリントゴールの内容がプロダクト価値にどのように貢献するか説明できればOKです。
開発者A初回のスプリントで動くものまで見せれるか不安だけど、ログイン機能の実装は開発者もイメージしやすいし、いいかもね！
スクラムマスタースプリントゴール達成へ向けて、POは今回のスプリントでどのプロダクトバックログアイテムを開発スコープとしたいのでしょうか？
スプリントゴールを達成するために、どのプロダクトバックログアイテムを完了させたいかPOが開発者へ共有します。
プロダクトオーナースプリントゴールの達成へ向けて、PBI＃1〜#3まで実施したいと考えています。
PBI#1：開発環境を構築する
PBI#2：勤怠管理システムのTop画面にアクセスできる
PBI#3：社員番号でログインできる
それぞれ、プロダクトバックログアイテムの詳細と受け入れ基準を説明します。
各PBIに対して、機能要件や非機能要件、想定している画面イメージや利用者からの要望などを説明します。
開発者はプロダクトオーナーの説明に不明点があれば質問するようにしましょう。
プロダクトバックログに関しては、以下の記事で解説しています。
スクラムマスターでは、開発者のみなさんでプロダクトバックログアイテムに対して、ストーリーポイントの見積りをお願いします。
見積り方法は、プラニングポーカーでいいですかね？
開発者A初回のスプリントではい、プラニングポーカーの見積りでOKです。
開発者のみなさん、PBI#1から順番にポイント見積りをしましょう！
プラニングポーカーとは、フィボナッチ数列(1,2,3,5,8,13…)の値を使って、
実施するプロダクトバックログアイテムの難易度を見積る方法です。
プラニングポーカーに関しては、以下の記事で解説しています。
開発者A見積りが終わりましたー！各PBIのポイントは以下です。
PBI#1：5ポイント
PBI#2：5ポイント
PBI#3：3ポイント
スクラムマスター見積りありがとうございます。
初回スプリントですので、このチームのベロシティはわかりませんが、
いくつかの別チームのベロシティを参考に初回スプリントのベロシティは15pt程度を想定しています。
開発者Aそうなんですね。では、ポイント見積りでは収まりそうですね。
スプリントのキャパシティを超えていないか確認するために、ポイントから実際の時間に変換して、スプリント計画を作成してみます。
スクラムマスターそうですね。
開発者の皆さんでスプリントバックログの作成をお願いします。
また、スプリントバックログアイテム洗い出し、時間見積り完了後に、
スプリントの作業時間を超えていないか確認をお願いします。
開発者Aそうなんですね。では、ポイント見積りでは収まりそうですね。
スプリントのキャパシティを超えていないか確認するために、了解です。
それじゃ、みんなでスプリントバックログアイテムを洗い出しと時間の見積りをしていこう。
スプリントバックログアイテムは、4時間以内で完了する粒度を目指しましょう。
また、ストーリーポイントではなく、実際に作業する時間で見積りをします。
スプリントバックログアイテムは、「サブタスク」や「タスク」と呼ぶこともあります。
スプリントバックログに関しては、以下の記事で解説しています。
開発者Aスプリスプリントバックログアイテムの洗い出しと見積りが終わりました。以下共有します。
PBI#1(14h)：開発環境を構築する
SBI#1(4h)：システム構成を検討す
SBI#2(4h)：AWSの利用申請をする(ロール作成も)
SBI#3(2h)：AWSのEC2でサーバーを立てる
SBI#4(2h)：AWSのRDSを作成する
SBI#5(2h)：AWSのElasticCacheを作成する
SBI#6(2h)：ドキュメント整備
PBI#2(21h)：勤怠管理システムのTop画面にアクセスできる
SBI#1(3h)：詳細設計書を作成する
（画面、シーケンス、DB構成）
SBI#2(1h)：ドメインを取得する
SBI#3(2h)：frontend(画面)を作成する
SBI#4(2h)：backendを作成する
SBI#5(4h)：concourseを利用しCI/CD環境を作成する
SBI#6(2h)：単体試験を実施する
SBI#7(3h)：結合試験書を作成する
SBI#8(2h)：結合試験を実施する
SBI#9(2h)：ドキュメント整備
PBI#3(16h)：社員番号でログインできる
SBI#1(2h)：詳細設計書を作成する
（画面、シーケンス、DB構成）
SBI#2(2h)：frontend(画面)を作成する
SBI#3(3h)：backendを作成する
SBI#4(3h)：単体試験を実施する
SBI#5(3h)：結合試験書を作成する
SBI#6(2h)：結合試験を実施する
SBI#7(1h)：ドキュメント整備
開発者B作業計画上もチームのキャパシティを超えていないので、問題ないです。
開発者の作業時間：6h/日 * 5日 * 3人 = 90h
スクラムイベントの時間：12.25h/人 * 3人 = 36.75h
スプリントバックログの作業時間：51h
90h – (36.75h + 51h) = 2.25h 余ります！
2週間スプリントで開発者が3人の場合で見積りを実施しています。
デイリースクラム：0.25h * 5日 * 3人 = 3.75
スプリントプラニンング：4h * 3人 = 12h
リファインメント：2h * 2日 * 3人 = 12h
スプリントレビュー：1.5h * 3人 = 4.5h
レトロスペクティブ：1.5h * 3人 = 4.5h
プロダクトオーナースプリントバックログと時間の見積りありがとうございます。
結構ギリギリですね。
初回スプリントなので、開発スコープを調整した方が良いでしょうか？
開発者A初回スプリントを考慮して、各SBIでリスクを積んでいるので問題ないです。
想定外のリスクが発生した場合は、リファイメントなどで調整させてください。
プロダクトオーナー了解です。
リファインメントは事前に設定させてもらいますね！
よろしくお願いします。
スクラムマスターPOと開発者の皆さんとの間で、今回のスプリントの開発スコープの合意が取れたと思いおます。
それでは「ユーザーが勤怠登録システムに社員番号でログインできるようにする」をスプリントのゴールとし、スプリント1を開始します！
よろしくお願いします。
開発者Aお願いします！
よくある失敗例・アンチパターン
スプリントプラニンングが上手く進められない要因として以下のようなものがあります。
みなさんのチームに当てはまっているものがないか確認しましょう！
[プロダクトオーナー]
・プロダクトビジョンがまとまっていない（明確に思いを伝えられない）
・プロダクトゴールやリリース計画を検討できていない
・プロダクトバックログの優先順位が定まっていない（基準が曖昧
・ステークホルダーの操り人形になっていて、開発者からの質問に答えられない
・チームのキャパシティを超えた開発スコープでスプリントを開始しようとしている
[開発者]
・プランニングの時点でプロダクトバックログアイテムの担当者を決めている
・スプリントバックログアイテムの洗い出しや見積りを分担して行なっている
・スプリントバックログアイテムを機械的に洗い出している
（ウォーターフォールの工程がそのまま書いてあるだけ）
・SBIの細分化で疲弊し、SBIを成し遂げられるかの確認が疎かになっている
とも坊より良いプライニングになるようにお互いに助け合いましょう！
同じチームであることを忘れないでね。
現場で活かせるノウハウ
スプリントプランニングの目的は、このスプリントで何を成し遂げるか認識を合わせることです。
認識合わせに時間がかかったり、開発スコープが定まらない場合の取り組みを共有します。
皆さんのチームで取り入れられそうなものがあれば、是非チャレンジしてみてください。
[プロダクトオーナー ]
・スプリントゴールやPBIの説明が伝わるか、プラニング前にSMに確認してもらう
・今後のスプリントで何を提供する予定か見える化し、開発者に共有する
※ 観点レベルで計画できて入ればOKです。
※ プロダクトビジョンとそのマイルストーンとなるプロダクトゴールを見える化しましょう。
・スプリント中に割り込み作業や追加要望が頻発する場合は、対応工数を予め計画に含める
※ スプリント開始後は、基本的に割り込みや追加要望はNGです。
※ 割り込みが継続する場合はインペディメントとして管理し、妨害要因を排除するのが理想ですが、
実際の現場では解消するまでに時間がかかるため、暫定対処としては効果的です。
[開発者]
・スプリントバックログアイテムの洗い出しを全員で実施する
・スプリントバックログアイテムの時間見積りを全員で実施する
・プロダクトオーナーと開発者の認識合わせを行う時間（質問タイム）を予め計画しておく
・PBIを成し遂げるためにHow調査や検討が必要な場合は「spike」を作成し、計画に含める
※ 何を持ってspikeを完了とするか、開発者の中で明確にできると良いですが、
難しい場合は、何ポイント分の稼働を割くか予め決め、その時間内で実施するようにしましょう
とも坊一度に全てのノウハウを試してみるのではなく、1つずつ取り組もう！
「スプリントプランニング」まとめ
[ポイント]
・スプリントプランニングは、スプリントの目標や作業内容を計画する時間
・タイムボックスは、1週間スプリントであれば2時間、2週間スプリントであれば4時間が目安
・スプリントプランニングで、プロダクトオーナーと開発者でスプリントゴールと開発スコープを合意する
・開発者は、PBIからスプリントバックログを作成する
・スプリントバックログは、4時間程度で完了する粒度とし、ポイントではなく時間で見積る
・SBIの作業時間とスクラムイベント参加時間の合計がスプリントの稼働時間を超えていないか確認する
参考資料
・SCRUM BOOT CAMP THE BOOK
・いちばんやさしいアジャイル開発の教本
・Ryuzen.com
スクラム関連のおすすめ記事
スクラム開発をもう少し勉強したい！と思った方は、以下の記事がおすすめです。
実際に私が読んだ本の中で「絶対に損しない」初心者が読みやすい本をピックアップしてレビューしています。
教本選びのご参考になれば幸いです。
本を読んでいる暇がない！活字は少し苦手。。。という方は、動画教材がおすすめです。
通勤中や就寝前などに必要なセクションのみ選択して学習できるため学習効率が非常に高いです。
また、近年アジャイル人材の需要が高まっています。
アジャイル人材の需要や年収などを以下の記事にまとめていますので、学習のモチベーション維持にお役立てください。
コメント