スプリントレビューの進め方（アジェンダと具体例）

スプリントレビューは、チームが実際に作り上げたものをお披露目する場です。うまく実施できれば、これはスプリントの中でも特に価値のある1時間になります。プロダクトを作った人たちと、それを使う人・資金を出す人との間で交わされる、本物の対話の時間です。

スプリントレビューとは

スプリントレビューは、各スプリントの終わりに開催される正式なScrumイベントです。チームはインクリメント(スプリント中に完成したものすべて)を検査し、そこから学んだことをもとにプロダクトバックログを調整するために、ステークホルダーと協力します。

Scrumガイド(Schwaber氏とSutherland氏、2020年)は、これをステータス報告や一方通行のデモではなく「作業セッション」と定義しています。この違いは重要です。ステークホルダーは観客ではなく、次に何を作るべきかをチームと一緒に決める参加者です。

スプリントレビューは、1か月のスプリントに対して最大4時間というタイムボックスが設けられています。スプリントが短ければレビューもそれに比例して短くなり、2週間スプリントを回すほとんどのチームは1~2時間に収めています。

重要なポイント

• Scrumガイド(2020年)は、1か月のスプリントに対して4時間のタイムボックスを定めており、スプリントが短い場合はそれに応じて縮小するとしています。
• スプリントレビューは、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ、そしてスプリント自体という、5つのScrumイベントの一つです。
• Digital.aiの2023年State of Agileレポートによると、回答者の71%がScrumまたはScrumのハイブリッド手法を使用しており、スプリントレビューはソフトウェア業界において最も広く実践されている構造化されたフィードバックの場の一つとなっています。

有用な捉え方として、スプリントレビューは「私たちは正しいものを作れたか」に答えるものです。一方、スプリントレトロスペクティブは「私たちは正しいやり方で作れたか」に答えるものです。

スプリントレビューとスプリントレトロスペクティブの違い

この2つのイベントは、各スプリントの終わりに連続して行われるため、チームはしばしば両者を混同してしまいます。しかし、これらは根本的に異なる種類の対話です。

レトロスペクティブの形式や質問の詳細については、スプリントレトロスペクティブのガイドを参照してください。

スプリントレビューには誰が参加するのか

Scrumガイドは、次の参加者を挙げています。

• Scrumチーム: インクリメントを作った開発者たち、Product Owner、そしてScrum Master
• ステークホルダー: 顧客、ユーザー、経営層、事業スポンサーなど、Product Ownerが招く人たち
• 専門家: 次に何を作るべきかの意思決定に役立つ知見を持つ専門家(任意)

通常、ステークホルダーを招くのはProduct Ownerの役割です。Scrum Masterは、イベントが生産的でタイムボックス内に収まるようにします。開発者はインクリメントを直接発表し、質問にも直接答えます。この直接性は意図的なものです。ステークホルダーは加工されていない情報を得られ、開発者は加工されていない反応を得られます。

スプリントレビューのアジェンダ

うまく構成されたスプリントレビューは、5つのパートで進みます。以下は、2週間スプリントで典型的な90分のレビューのサンプルアジェンダです。

パート1: オープニング(10分)

Product Ownerが、スプリントゴールの振り返りと、そのスプリントで計画していた項目のリストから始めます。ここは省略しないでください。スプリントプランニングに参加していなかったステークホルダーには、デモを見る前に文脈が必要です。

パート2: インクリメントのデモ(40分)

開発者が動くソフトウェアを実演します。スライドではなく、実際のソフトウェアです。デモはスプリントゴールと直接結びついたものであり、受け入れ基準が満たされていることを示すものであるべきです。各機能は、無難に整えられた説明ではなく、現実的なシナリオの中でデモされるべきです。

ヒント: それぞれの開発者に、自分が作った機能を割り当てましょう。背景を説明し、機能を実演してもらいます。一人がすべてをデモするよりも、こちらの方が説得力があります。

パート3: ステークホルダーからのフィードバック(20分)

ここがスプリントレビューの核心です。Product Ownerが自由な対話をファシリテートします。有用なフィードバックを引き出すための質問例は次の通りです。

• これは想定していた課題を解決していますか?
• これをもっと役立つものにするには何が必要ですか?
• 次は何に注力すべきですか?
• 何か抜けているもの、あるいは間違っているものはありますか?

すべてを記録しましょう。ステークホルダーの意見は、次のバックログ更新に直接反映されます。

パート4: バックログレビュー(15分)

Product Ownerが、更新後のプロダクトバックログを説明します。ここが、そのスプリントで得られた学びが今後の作業に落とし込まれる場です。新しい項目が浮かび上がり、優先順位が入れ替わります。チームとステークホルダーは、次に何を重視すべきかについて認識を合わせます。

パート5: クロージング(5分)

次のスプリントゴールを予告し、次回レビューの日程を確認し、ステークホルダーに感謝を伝えます。短く、明確に。

効果的なスプリントレビューの進め方

ステップ1: デモ環境を事前に準備する

レビュー当日の朝まで待たないでください。前日のうちに、ステージング環境を用意し、デモ用アカウントが動作することを確認し、実際に使う外部連携があればテストしておきましょう。デモが失敗すると、全員の時間を無駄にし、信頼を損ないます。

ステップ2: 事前にステークホルダーに情報を伝えておく

短い事前資料を送りましょう。スプリントゴール、何をデモするか、そして関連する背景情報(改善しようとしているユーザーのワークフロー、修正したバグなど)です。ステークホルダーは、出発点を理解していればいるほど、より良いフィードバックをくれます。

ステップ3: 動くソフトウェアだけを見せる

Definition of Doneを満たしたものだけを見せましょう。80%しか完成していないものはデモしないでください。未完成の作業を見せると、混乱や期待値のずれを生みます。インクリメントとは、チームの「完了」の基準を満たしたものだけを指します。

ステップ4: 適切なステークホルダーを招く

人数が多ければ良いというわけではありません。意思決定の権限を持つ人、あるいはユーザーについて直接的な知見を持つ人を招きましょう。関心の高い5人の少人数グループの方が、受け身な20人の観客よりも、良いフィードバックを生み出します。

ステップ5: フィードバックをリアルタイムで記録する

議論の間、一人にステークホルダーの意見を記録する役割を割り当てましょう。実行可能な項目は、セッションが終わる前にそのままバックログに入れるか、少なくともProduct Ownerが直後に処理できるよう印をつけておきます。

ステップ6: 明確な次のステップで締めくくる

会場が解散する前に、次のスプリントで見込まれる注力点を伝えましょう。それが最終決定である必要はありません。しかし、共有された方向性が何もないまま解散してしまうのは、機会損失です。スプリントレビューは、一つの章が閉じ、新しい章が開くような感覚であるべきです。

スプリントレビューのベストプラクティス

• デモは現実的に保ちましょう。 実際のデータ、あるいはそれに近いシナリオを使いましょう。作り物めいたデモでは、本当のユーザビリティの問題が浮かび上がってきません。
• 各デモのセグメントにタイムボックスを設けましょう。 見せるべき項目が5つあるなら、それぞれに時間を割り当てましょう。構造がないと、デモが長引き、フィードバックの時間が圧迫されます。
• 発表者をローテーションしましょう。 各開発者が自分の作った機能を発表することで、チームの自信が育ち、ステークホルダーもチームの姿をより明確に理解できます。
• レトロスペクティブのテーマを混ぜ込まないようにしましょう。 プロセスに関する課題はレトロで扱うべきものです。レビュー中にステークホルダーがチームのプロセスに関する懸念を提起した場合は、それを記録し、レトロに委ねましょう。
• 重要な意思決定を記録しましょう。 ステークホルダーが承認したことは何か。優先順位を下げたものは何か。新たに浮かび上がった要望は何か。こうした意思決定には記録が必要です。

よくある間違い

レビューを一方通行のデモとして扱ってしまうこと。 ステークホルダーがただ見て拍手するだけなら、価値を取りこぼしています。スプリントレビューは共同作業のセッションであり、劇場のパフォーマンスではありません。

未完成の機能をデモしてしまうこと。 作業途中のものをあたかも完成しているかのように見せると、信頼が損なわれます。準備ができていないものは、正直にそう伝えましょう。省略するか、明確な注釈をつけて簡単に見せるにとどめてください。

バックログの議論を省略してしまうこと。 デモをして終わりにしてしまうチームは、最も重要な部分、つまり今学んだことによって何が変わるのかを見落としています。バックログの議論こそが、そのスプリントの成果を次のスプリントのインプットへと変える場です。

適切なステークホルダーなしで実施してしまうこと。 社内メンバーだけのスプリントレビューは、単なるチーム内の情報共有にすぎません。価値は、外部の視点や実際のユーザーからのフィードバックから生まれます。

準備をしないこと。 その場しのぎのデモは、しばしば失敗するか時間を超過します。前日にざっと確認する簡単な準備チェックリストがあれば、スプリントレビューにおけるほとんどの失敗を防げます。

よくある質問

スプリントレビューとは何ですか?

スプリントレビューは、各スプリントの終わりに開催されるScrumイベントで、チームが完成したインクリメントをステークホルダーに披露し、プロダクトバックログを更新するためのフィードバックを集める場です。これは正式なプレゼンテーションやステータス報告ではなく、共同作業のセッションです。

スプリントレビューはどのくらいの長さにすべきですか?

Scrumガイドは、1か月のスプリントに対して最大4時間を推奨しています。2週間スプリントの場合、ほとんどのチームは1~2時間でレビューを行っています。タイムボックスはスプリントの長さに比例します。スプリントが短ければ、レビューも短くなります。

スプリントレビューとスプリントレトロスペクティブの違いは何ですか?

スプリントレビューはプロダクトに焦点を当て、チームが作ったものを見せ、ステークホルダーがフィードバックを行います。一方、スプリントレトロスペクティブはチームのプロセスに焦点を当て、どのように協働したか、何を改善すべきかを扱います。どちらもスプリントの終わりに行われますが、目的も参加者も異なります。

スプリントレビューは誰が進行しますか?

通常はProduct Ownerがスプリントレビューをファシリテートし、セッションを開始し、バックログの議論をリードします。Scrum Masterは、イベントがタイムボックス内に収まり、生産的であるようにします。開発者はインクリメントを直接発表します。

スプリントゴールが達成できなかった場合はどうなりますか?

チームは完了した部分だけをデモします。未完成の項目を完了したものとして発表することはありません。計画していたことと実際に届けられたことの差は、バックログの更新とレトロスペクティブの両方にとってのインプットになります。結果を取り繕おうとするよりも、ここでの透明性の方がはるかに価値があります。

---

スプリントレビューは、Scrumイベントの中でも実施が最もシンプルな部類に入る一方で、うまくいかなくなるのも簡単なイベントの一つです。適切なステークホルダーが同席した、短く、しっかり準備されたデモは、すべてのスプリントを本物のフィードバックループに変えます。そして、それこそが、チームをただ速く作るだけでなく、正しいプロダクトを作り続けさせてくれるものなのです。

他のScrumイベントについては、アジャイルの儀式とデイリースタンドアップから見ていくとよいでしょう。