【簡単解説】スプリントプラニングの基本ルール・失敗例

スクラムイベント

この記事では、
・スプリントプランニングってなに?
・スプリントプランニングの正解がわからない
と悩んでいる方に向けて

・スプリントプランニングの基本ルール・やり方
・スプリントプラニングの具体例や失敗例
を説明します。

この記事を読むと以下のことがわかります。

この記事で読んでわかること!
  • スプリントプランニングの概要が理解できる
  • スプリントプランニングのやり方がわかる
  • スプリントプランニングの失敗例やノウハウを知れる

スクラムイベントの概要を確認したい方は、以下記事をご確認ください。

【習得必須】5つのスクラムイベントの概要を簡単解説
スクラムイベントの概要や推奨されるスプリント期間、スプリント中のスケジュール、各イベントの参加者や発言権に関して説明しています。各スクラムイベントの詳細を学習する前に、スクラムイベントの全体像をしっかりと把握・理解しておきましょう!

スプリントのスケジュールでいうと以下の赤枠部分です。

※この記事では以下の略称を使用します。
 PO = プロダクトオーナー
 SM = スクラムマスター
 PBL = プロダクトバックログ
 PBI = プロダクトバックログアイテム
 SBL = スプリントバックログ
 SBI = スプリントバックログアイテム
 AC = 受け入れ基準(Acceptance Criteria)

スプリントプランニングとは?

agile-planning

スプリントプランニングとは、スプリントのゴールを話し合い、そのゴールを達成するために必要な作業を計画するイベントです。5つのスクラムイベントのうち、スプリントの一番はじめに実施します。スプリントプランニングでは、これから実施するスプリントでユーザーにどんな価値を提供するか話し合い、それを実現するためのプロダクトバックログアイテムを決定し、どのように進めるか、どのくらい時間がかかるかを見積ります。

とも坊

スクラムチーム全員で、スプリントゴールや実施するPBIの実装方法を検討する大切な時間だよ!

スプリントプランニングの目的・メリット

[目的]
スプリントプランニングを通して、スプリントゴールや開発スコープ、プロダクトバックログアイテムの作業内容の認識を合わせることが目的です。

スプリントプランニングを実施することで得られる具体的なメリットは以下です。
[メリット]
・スプリントゴールを明確にすることで、スプリントの目的や作業に集中できる
・実施するPBIに関して、その場でPOに不明点を確認できるため、後々の認識齟齬が少なく済む
・PBIの実現可能性や実装方法に対して開発者の間で認識合わせをすることができる

(見積り精度が向上する)

スポンサーリンク

スプリントプランニングの基本ルール

タイムボックス
以下の時間を目安に設定する。
1週間スプリントの場合:2時間
2週間スプリントの場合:4時間
(スクラムガイドでは、1ヶ月スプリントで最大8時間とされています。)

参加者/発言権

agile-planning-participant

※アドバイザーとして、実行タスクに精通したステークホルダーをを招待するもの可能です。
※スクラムマスターは、プランニングが正しく運営されるようにファシリーテートは可能です。

やること
[プロダクトオーナー]
今回のスプリントで達成したいゴール(スプリントゴール)とその理由を開発者に宣言する
プロダクトバックログアイテムの詳細説明及び受け入れ基準(AC)を説明する
チームのベロシティと見積り結果から、スプリントの開発スコープを開発者と合意する
・スプリントゴールを達成するために、実施したいプロダクトバックログアイテムを提案する
・プロダクトバックログアイテムに対する開発者からの質問に回答する
・必要に応じてプロダクトバックログアイテムを見積りがしやすいように細分化する
・プロダクトバックログアイテムの見積りを開発者に依頼する
・開発者から見積根拠を確認し、不明点があれば確認する

[開発者]
開発者全員でプロダクトバックログアイテムのストーリーポイントを見積る
スプリントゴール達成がプロダクトビジョンやユーザーへの価値に繋がるか確認する
プロダクトバックログアイテムの説明で不明点があればプロダクトオーナーに質問する
 ※ 見積りをするために必要な情報が提示されているか確認しましょう。
 ※ 機能要件だけでなく、非機能要件や画面イメージ、運用要件なども観点も忘れずに!
PBIを実施するために必要なスプリントバックログアイテムを洗い出す
 ※ スプリントバックログアイテムは4時間以内で完了できる粒度にする
実施対象のプロダクトバックログアイテムがスプリント内で完了可能か見積る
 ※ 実働時間 > 見積作業時間 + スクラムイベントの時間
チームのベロシティと見積り結果から、スプリントの開発スコープをプロダクトオーナーと合意する
・スプリントゴールとその実施理由が適切か確認する
・1つのプロダクトバックログアイテムが1日以上かかるボリュームの場合は細分化を依頼する
・見積り根拠をプロダクトオーナーに説明する

[スクラムマスター]
・スクラムチームがスプリントプランニングの目的を理解できるように説明する
・スプリントプランニングがスムーズに進むようにファシリテートする
プロダクトオーナーがチームキャパシティを超えた依頼を強行しようとしている場合は、代替案検討やステークホルダーへの調整を促す

作成物
・スプリントバックログ
スプリントゴール、実施対象のプロダクトバックログアイテム、PBIを細分化したスプリントバックログアイテムからなる。

スプリントプランニングのやり方

【基本的な流れ】

第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. プロダクトオーナーと開発者でスプリントゴールと開発スコープを合意し、スプリントを開始する

スプリントプランニングの具体例・イメージ

スクラムマスター

スプリント1のスプリントプランニングをはじめます。
はじめにプロダクトオーナーから、今回のスプリントゴールの共有をお願いします。

スプリント1のスプリントゴールはズバリ!
「ユーザーが勤怠登録システムに社員番号でログインできるようにする」です。
初回のスプリントでは、開発環境の構築に時間がかかる想定していますが、ステークホルダーがシステムのイメージを掴めるように、実際に動かせるものを開発したいです。
なので、今回のスプリントでは、勤怠登録システムのTop画面から社員番号でログインできるところまでゴールとしたいです。

プロダクトオーナー
開発者A

初回のスプリントで動くものまで見せれるか不安だけど、ログイン機能の実装は開発者のイメージを認識齟齬は少なさそうだしいいかもね!

スプリントゴールの達成へ向けて、PBI#1〜#3まで実施したいと考えています。
PBI#1:開発環境を構築する
PBI#2:勤怠管理システムのTop画面にアクセスできる
PBI#3:社員番号でログインできる
それぞれ、プロダクトバックログアイテムの詳細と受け入れ基準を説明します。

プロダクトオーナー

各PBIに対して、機能要件や非機能要件、想定している画面イメージや利用者からの要望などを説明します。開発者はプロダクトオーナーの説明に不明点があれば質問するようにしましょう。

スクラムマスター

では、開発者のみなさんでプロダクトバックログアイテムに対して、ストーリーポイントの見積りをお願いします。
見積り方法は、プラニングポーカーでいいですかね?

はい、プラニングポーカーの見積りでOKです。
開発者のみなさん、PBI#1から順番にポイント見積りをしましょう!

開発者A

プラニングポーカーとは、フィボナッチ数列(1,2,3,5,8,13…)の値を使って、実施するプロダクトバックログアイテムの難易度を見積る方法です。プラニングポーカーの説明は別記事で説明予定です。

開発者A

見積りが終わりましたー!各PBIのポイントは以下です。
PBI#1:5ポイント
PBI#2:5ポイント
PBI#3:3ポイント

見積りありがとうございます。
初回スプリントなので、このチームのベロシティが何かわからいけど、同じ2週間スプリントの別チームの初回ベロシティは15ptだったみたいなので収まりそうかな?

プロダクトオーナー
スクラムマスター

そうですね。他のプロジェクトの状況からも無理があるゴールではないと思います。
一旦、PBI#1〜3までを開発スコープとし、スプリントバックログの作成をお願いします。
また、スプリントバックログアイテムの作成、見積り後、スプリントの作業時間のキャパシティを超えていないかも確認をお願いします。

了解です。
それじゃ、みんなでスプリントバックログアイテムを洗い出しと時間の見積りをしていこう。

開発者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):ドキュメント整備

作業計画上もチームのキャパシティを超えていないので、問題ないです。
開発者の作業時間:6h/日 * 5日 * 3人 = 90h
スクラムイベントの時間:12.25h/人 * 3人 = 36.75h
スプリントバックログの作業時間:51h
90h – (36.75h + 51h) = 2.25h 余ります!

開発者B

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

プロダクトオーナー

スプリントバックログと時間の見積りありがとうございます。
初回スプリントにも関わらず、残時間が少ないように感じますが、開発スコープを調整した方が良いでしょうか?

初回スプリントを考慮して、各SBIでリスクを積んでいるので問題ないです。
想定外のリスクが発生した場合は、リファイメントなどで調整させてください。

開発者B
プロダクトオーナー

了解です。
開発者の皆さんの合意も取れましたので、「ユーザーが勤怠登録システムに社員番号でログインできるようにする」をスプリントのゴールとし、PBI#1〜3を開発スコープとしてスプリント1を開始します!
よろしくお願いします。

スプリントプラニングのよくある失敗例

スプリントプラニンングが上手く進められない要因として以下のようなものがあります。
みなさんのチームに当てはまっているものがないか確認しましょう!

[プロダクトオーナー]
・プロダクトビジョンがまとまっていない(明確に思いを伝えられない)
・プロダクトゴールやリリース計画を検討できていない
・プロダクトバックログの優先順位が定まっていない(基準が曖昧)
・ステークホルダーの操り人形になっていて、開発者からの質問に答えられない
・チームのキャパシティを超えた開発スコープでスプリントを開始しようとしている

[開発者]
・プランニングの時点でプロダクトバックログアイテムの担当者を決めている
・スプリントバックログアイテムの洗い出しや見積りを分担して行なっている
・スプリントバックログアイテムを機械的に洗い出している
 (ウォーターフォールの工程がそのまま書いてあるだけ)
・SBIの細分化で疲弊し、SBIを成し遂げられるかの確認が疎かになっている

とも坊

できていないことに文句を言うのではなく
チームで取り組んでいることを忘れずに、
より良いプライニングとなるようにお互いに助け合いましょう!

スプリントプランニングで活かせるノウハウ

スプリントプランニングの目的は、このスプリントで何を成し遂げるか認識を合わせることです。
認識合わせに時間がかかったり、開発スコープが定まらない場合の取り組みを共有します。
皆さんのチームで取り入れられそうなものがあれば、是非チャレンジしてみてください。

[プロダクトオーナー]
・スプリントゴールやPBIの説明が伝わるか、プラニング前にSMに確認してもらう
・今後のスプリントで何を提供する予定か見える化し、開発者に共有する
 ※ 観点レベルで計画できて入ればOKです。
 ※ プロダクトビジョンとそのマイルストーンとなるプロダクトゴールを見える化しましょう。
・スプリント中に割り込み作業や追加要望が頻発する場合は、対応工数を予め計画に含める
 ※ スプリント開始後は、基本的に割り込みや追加要望はNGです。
 ※ 割り込みが継続する場合はインペディメントとして管理し、妨害要因を排除するのが理想ですが、
  実際の現場では解消するまでに時間がかかるため、暫定対処としては効果的です。

[開発者]
・スプリントバックログアイテムの洗い出しを全員で実施する
・スプリントバックログアイテムの時間見積りを全員で実施する
・プロダクトオーナーと開発者の認識合わせを行う時間(質問タイム)を予め計画しておく
・PBIを成し遂げるためにHow調査や検討が必要な場合は「spike」を作成し、計画に含める
 ※ 何を持ってspikeを完了とするか、開発者の中で明確にできると良いですが、
   難しい場合は、何ポイント分の稼働を割くか予め決め、その時間内で実施するようにしましょう

とも坊

一度に全てのノウハウを試してみるのではなく、スプリントを重ねる中で一つずつ取り入れてみましょう!

まとめ

  • スプリントプランニングは、スプリントの目標や作業内容を計画する時間
  • タイムボックスは、1週間スプリントであれば2時間、2週間スプリントであれば4時間が目安
  • スプリントプランニングで、プロダクトオーナーと開発者でスプリントゴールと開発スコープを合意する
  • 開発者は、PBIからスプリントバックログを作成する
  • スプリントバックログは、4時間程度で完了する粒度とし、ポイントではなく時間で見積る
  • SBIの作業時間とスクラムイベント参加時間の合計がスプリントの稼働時間を超えていないか確認す

参考資料

SCRUM BOOT CAMP THE BOOK
いちばんやさしいアジャイル開発の教本
Ryuzen.com
Sponsored Link

コメント

タイトルとURLをコピーしました