スクラムを構成する5つの会議体
はじめに
この度、開発チームにスクラム開発を取り入れることになりました。スクラムには複数の会議体があるのですが、これらの会議体の目的やつながりをまとめたく、この記事を作成しました。少し長いため、目次をご活用ください。
5つの会議体の概要
スクラム開発では、検査と適応を行う機会として、5つの会議体があります。5つの会議体のうち4つはSprint内での開催が必須ですが、残り1つは任意で開催します。
本記事では、下記の5つの会議体の概要を示し、最後に、各会議体の開催順序について説明します。
❕ご注意
この記事はスクラムガイド2020をベースとしたうえで、所属チームでの進め方に合うようにカスタマイズしたものです。一部スクラムガイドと記述が異なる箇所がありますが、ご容赦ください。
開催が必須な4会議
Sprint Planning
目的
この会議の目的は、スプリントで達成すべき目標およびスプリントで実行する作業を計画します。スクラムチームは、スプリントゴールおよび、開発者が着手するスプリントバックログアイテム決めます。
成果物
Sprint Planning終了時に求められる成果物は下記の2つです。
Sprint Goal
Sprint Goalは、このSprintでスクラムチームが集中すべき唯一の目的です。Sprint Goalは1～2行の文章で定義し、チーム内外のメンバーがいつでも確認できる場所に掲げます
Sprint Backlog (SBL)
開発者がこのSprintで取り組む予定のBacklog Itemの一覧です。Jiraなどのツールで管理します
開催タイミング
Sprint開始直後（Sprintの最初に行う活動）
確保できる時間
この会議に使用できる時間は、1か月あたり最大8時間までです。一週間スプリントの場合、最大2時間を目安にすると良いでしょう。
参加者
PO (プロダクトオーナー)
開発者
スクラムマスター
ワンポイント
Sprint Planningが時間内に終わらない原因は？
Product Backlog Item(PBI)の粒度が大きすぎたり、ポイントが付いているPBIが少ないことが原因の一つです。Sprint Planning開始時点で、2～3Sprint先に取り組む予定のPBIが適切な大きさに分割できており、ポイントがついている状態にすると、Sprint Planningをスムーズに進められます。併せて、Backlog Refinementの章を参考にしてください。
Sprint Backlogに入れるべきPBIの目安数は？
Sprint Backlog(SBL)に入れるPBIの数は次の2つの条件を目安として決めると良いでしょう
最小条件: Sprint Goalを達成すべき最低限のPBIが入っていること
最大条件: PBIのポイントの合計値が平均Velocity以下であること
PBIのポイントの合計値が平均Velocityを超えてもSprint Goalを達成できない場合、非現実的なSprint Goalを設定しているサインです。Sprint Goalを再設定してください。
祝日やメンバーの離脱などで稼働日数が減る場合は、平均Velocityから稼働日数を控除した値を使用すると良いです。（例: 週5日のうち祝日が1日ある場合、平均Velocityに0.8を掛けた値を使う）
Daily Scrum
目的
この会議の目的は、Sprint Goalに対する各メンバーの進捗を確認することです。各メンバーからの共有を受けた後に、本日のチーム全体での動きを合意します。例えば、Sprint Goal達成が危ぶまれる場合、POに相談するなどのアクションを決定します。
成果物
Daily Scrumの終了時の成果物は特にありませんが、下記の2つが明確になっていると良いです。
各チームメンバの作業内容および障害がチームに共有されていること
チームとして本日取る行動が明確になっていること
上記の内容を明文化するために、Daily Scrumで議事録を取ることをオススメします。
開催タイミング
毎日（朝一に実施することが多い）
確保できる時間
この会議に使用できる時間は、1日あたり最大15分までです。時間が過ぎても延長せず終わらせるようにしましょう。
参加者
開発者
スクラムマスター
上記メンバー以外も傍観者として参加することができますが、Daily Scrumの内容に口を挟むことはできません。
Sprint Goalを達成するための方針や手段は、開発者の裁量で決めるべきだからです。
ワンポイント
毎日のDaily Scrumでは、Sprint Goalを共有する
Sprint期間中は、どうしても作業をこなすことに目が行きがちです。Sprint Goalを思い出し、チームの目線を合わせるために、Daily Scrumの頭でSprint Goalを読み上げると効果的です。
Daily Scrumでは、各メンバーに質問を投げかける
私の所属するチームでは3つの質問を投げかけます
昨日やったこと
今日やること
Sprint Goal達成を阻む障害
Sprint Goalに対する進捗の検査をする
Daily Scrumでは、バーンダウンチャートやSBLにある未完成のPBIを確認しましょう
Sprint Goal達成が難しいことが分かった場合、すぐにPOにその旨を連絡します
Sprint Review
目的
この会議の目的は、Sprintの結果を検査し今後の適応を決定することです。今Sprintでの成果物（インクリメント）に対し、ステークホルダーからのフィードバックをもらい、スクラムチームの進むべき方向が間違っていないかを確認します。Sprint Reviewにより、開発方針のズレやステークホルダーの期待値を明確にすることが目的です。
成果物
Sprint Review終了時に求められる成果物として、下記の2つが決まると良いです。
次Sprintで取り組むテーマを決める
ステークホルダーからのフィードバックを踏まえ、スクラムチームが次に取り組むべきSprintのテーマを決めます。ここで言うテーマとは次Sprint Goalの元となる開発の方向性を示した短文のことです。Sprint Review中にテーマを決められれば、ステークホルダー側もスクラムチームが次Sprintで取り組む方向性を認識しやすくなります。
ステークホルダーからの指摘事項をPBIに反映する
Sprint Review中に指摘された項目は、PBIにメモとして追記します。場合によって、優先度が高くなったPBIをバックログの上部に並べ替えても良いです。
開催タイミング
Sprint期間の最終日付近（Sprint Retrospectiveの前）
確保できる時間
この会議に使用できる時間は、1か月あたり最大4時間までです。一週間スプリントの場合、最大1時間を目安にすると良いでしょう。
参加者
ステークホルダー
PO (Product Owner)
開発者
スクラムマスター
ワンポイント
Sprint Reviewで検査するもの
本Sprintでスクラムチームが生み出したビジネス的価値（インクリメント）を検査します。ステークホルダーのフィードバックをもらいながら、チームがプロダクトゴールの方向に正しく向かっているか検査します。
Sprint Reviewで検査しないもの
スクラムチームの仕事の進め方や、チーム体制の課題などは検査の対象にはなりません。これらはSprint Retrospectiveで振り返ります。
Sprint Retrospective
目的
この会議の目的は、スクラムチームの仕事の進め方を振り返り、次Sprint以降での改善点を会話することです。
成果物
Sprint Retrospective終了時の成果物として、次Sprintでチームが取り組むべき改善策を2〜3つ決めることです。
各メンバーが何をすればよいか分かるような具体的な改善策を決めます。
改善策の例
Good ... Daily Scrumの時間が超過しているため、15分で会議を打ち切る
Bad ... レビュー待ちの pull request が溜まっているため、各人が積極的にレビューする（改善策が曖昧なため❌）
開催タイミング
Sprint最終日（この会議の終了とともに、Sprintが終了します。）
確保できる時間
この会議に使用できる時間は、1か月あたり最大3時間までです。一週間スプリントの場合、最大30分を目安にすると良いでしょう。
参加者
PO (Product Owner)
開発者
スクラムマスター
ワンポイント
どんな振り返り手法がありますか？
振り返り手法として複数の方法がありますが、例としてKPT法をご紹介します。
Keep
Sprintを進める中で、上手くいっている活動を可視化し、続けたいことをリストアップします。
Problem
Sprintを進める中で、スクラムチーム内で抱えている課題を顕在化させます。
Try
次のSprintでスクラムチームが取り組むべき具体的なアクションプランを決めます。Tryでは、KeepとProblemの内容をチームで会話したうえで、2～3つの具体的な改善策を決定します。
Sprint Reviewとの違いは？
Sprint Reviewがチームが生み出した成果物に対する検査が目的なのに対し、Sprint Retrospectiveはチーム内部の状態を検査することが目的です。
PO(Product Owner)は参加すべきか？
Sprint RetrospectiveにPOは参加すべきと考えます。POが不参加だと、スクラムチームの課題が開発者内部に囲われ、POと開発者の間に壁ができやすくなるからです。
また、スクラムではPOに起因する課題は比較的多く出るので、Sprint RestrospectiveではPOと開発者間で積極的にコミュニケーションを取りましょう。
開催が必須でない1会議
Backlog Refinement
目的
この会議の目的は、Product Backlog(PBL)の優先度を見直し、優先度の高いPBIを正しい粒度まで分割することです。
この会議でPBLが整理されていると、次のSprint Planningがスムーズに進行します。
成果物
Backlog Refinement終了時に求められる成果物として、下記の3つが完了していると良いです。
直近2～3Sprint先で実施予定のPBIが優先度順に並び替えられていること
プロダクトオーナーと開発者が会話しながら、直近数Sprint先までのPBIを優先度順に並び替えます。この作業によりスクラムチームが直近どんな作業に着手するのかの透明性が保たれます。
次のSprint Planningがスムーズに進行するように、直近Sprintで実施予定のPBIが1日以下の粒度に分割されていること
直近Sprintで着手予定のPBIのポイントが見積もられていること
RefinementでPBIのポイントが正しく見積もられていれば、Sprint Planningの時間を大幅に短縮できます。
開催タイミング
任意のタイミングで開催（週に何回開催しても良い）
確保できる時間
この会議に使用できる時間に特に決まりはありませんが、1週間あたり最大2時間を目安にすると良いでしょう。
参加者
PO (プロダクトオーナー) ... 必須
開発者 ... 必要なメンバーのみ出席
スクラムマスター ... 必要に応じて参加
ワンポイント
Sprint PlanningとBacklog Refinementの目的の違いは？
Sprint PlanningはSprint Goal達成のために必要なPBIを「選択」することに主眼が置かれます。一方で、Backlog Refinementは、PBL内のPBIを「整理」し、PBIの優先順位をつけることが目的です。
Backlog Refinementは、Sprint Planningを円滑に進めるための補助的な立ち位置です。
5つの会議体の開催順序
ここまで、スクラム開発で開催される計5つの会議体について説明しました。これら5つの会議は下記の順で開催されます。
開催順序
Backlog Refinement（Sprint N-1 で開催)
Sprint Planning（Sprint N の最初に開催)
Daily Scrum（Sprint N 期間中に開催)
Sprint Review（Sprint N の最後から2番目に開催)
Sprint Retrospective（Sprint N の最後に開催)
最後に、5つの会議体の時系列的な流れを図にしました。
スプリントを区切りとして、5つの会議体が周期的に繰り返されていることが分かります。
