ブログ

ryuzeeによるブログ記事。不定期更新

スプリントレビューの進め方

みなさんこんにちは、@ryuzeeです。

スクラムにおいてはフィードバックが重要です。プロセスに対するフィードバックはスプリントレトロスペクティブ、プロダクトに対するフィードバックはスプリントレビューを活用します。

今日はスプリントレビューについて、一般的な手順や注意点を紹介します。

スプリントレビューの目的

まず最初にスプリントレビューの目的を再確認しておきましょう。スクラムガイドの最新版では、スプリントレビューを以下のように定義しています。

スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。

ちょっと分かりにくいので順番を入れ替えて説明しておきましょう。 スプリントレビューの目的は、インクリメントを提示することで、フィードバックや協力を引き出すことです。その背後にあるのはプロダクトの価値の最適化です。 フィードバックを踏まえて、プロダクトバックログアイテムを追加したり削除したり順番を入れ替えたりして、限られた時間や予算の中で価値を最大にできるように向かう先を修正していきます。 つまり、スプリントレビューは単なる進捗報告会ではありません。

スプリントレビューの参加者

スプリントレビューの参加者は、スクラムチームと、そのプロダクトに関わるステークホルダーです。

ここで重要なのはステークホルダーです。ステークホルダー不在で、スクラムチームだけでスプリントレビューを行っても不十分です。

例えば、ステークホルダーには、企画、マーケティング、営業、サポート、QA、実際の利用者、連携先システムの担当者、自分の部門のマネジメントの人などが含まれます。 いつも関係者全員を呼ぶのではなく、その時のスプリントゴールやプロダクト全体の進捗にあわせて、必要な時に必要な人を呼べば良いでしょう。ベロシティの低いチームが、忙しいステークホルダーを毎週呼んでデモを見せようとしたら、途中から来なくなってしまいます。

なお、これらのステークホルダーがスプリントレビューにどうしても来られない場合は、プロダクトオーナーは直接時間を取って訪問しフィードバックを貰っても構いませんし、そうすべきです。

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

では、実際にスプリントレビューのアジェンダがどのようなものになるのか見てみましょう。あくまで一例なので、組織やプロダクトに応じて変更を入れたり、レトロスペクティブでスプリントレビューのやり方自体も見直していってください。

  • 1. チェックイン、目的の共有
    • まず、簡単にスプリントレビューの目的やタイムボックスやワーキングアグリーメントを説明します
    • 開発チームにとってはステークホルダーとの数少ない接点なので、そのステークホルダーが初参加なのであれば名前や役割などを自己紹介しておきます
  • 2. 前提事項の共有
    • このスプリントレビューでの前提事項も共有しておきます。例えば、画面デザインに関しては別途入れ替えるのでデザインに関するフィードバックは不要、などと共有しておくと、参加者も集中しやすくなります
  • 3. これからデモする内容についての概要を説明
    • 今回のスプリントのスプリントゴールがどのようなもので、なぜそのゴールになっているのか、どのように重要なのか、誰にとって役に立つのかなどを説明します
    • スプリントゴールを踏まえて、今回のスプリントで選択したプロダクトバックログアイテムを共有し、完成しているものは何か、完成していないものは何かを明らかにします
  • 4. 今スプリントで完成したもののデモとフィードバック、Q&A
    • デモをするのは完成したプロダクトバックログアイテムです
    • デモを誰がやるのかについて特に決まりはありませんが、プロダクトオーナーは参加者のフィードバックを書き留めたり、議論に参加する必要があるので、開発者にやってもらった方が進めやすいでしょう
    • デモの説明や操作は作り手の視点よりも実際のユーザーの視点である方が好ましいと言えます。ステークホルダーもその視点で見るからです
    • ステークホルダーによってはコンテキストが分からないこともあるので適宜補足しながら進めます
  • 5. スプリント中の状況の変化などの共有と議論
    • スプリント中に分かった大きな課題や状況の変化を共有します。ステークホルダーによってはそれによって大きな影響を受ける人がいるかもしれません。その場合はなんらかのフィードバックが得られるはずです
  • 6. 今後の見通しや直近のスプリントでやろうとしていることの共有
    • 次回のスプリントの予定、特定のマイルストンに向けた着地の見通しなどを共有します
  • 7. まとめ

スプリントレビューの事前準備

スプリントレビューのアジェンダの例を見ると、事前準備が必要であることが分かるはずです。 スプリントレビュー自体はフォーマルな会議ではないので、過度に準備しすぎてはいけませんが、準備をしなさすぎると、折角集まってくれたステークホルダーの時間をムダにし、フィードバックも得られなくなってしまいます。 準備の目安はおおよそ1時間程度と考えておくと良いでしょう。

主な準備の内容は以下のようなものです。

  • プロダクトオーナーは事前にプロダクトバックログアイテムの受入判定を済ませる
    • 完成したプロダクトバックログアイテムがデモの対象となるので、プロダクトオーナーはあらかじめプロダクトバックログアイテムのそれぞれが完成しているのか完成していないのか判定しておく必要があります。なおスプリントレビューの前日や当日にまとめてやろうとすると多くの場合は辛いことになります
  • スプリントレビューでのデモ手順やシナリオの確認
    • デモ用の端末やデモ環境にプロダクトを入れて、動作するかを確認しておきます
    • また、複数人で連携してデモする場合には役割分担決めておきます
  • 最新のプロダクトバックログ
    • 適宜プロダクトバックログのリファインメントをしていれば問題ないと思いますが、最新版を用意しておき、次のスプリントで検討している内容や今後の見通しなどを説明できるようにしておきます
  • プレゼンテーションなどの簡単な説明資料の準備(必要であれば)
    • アジェンダ、プロダクトバックログの説明、この後の予定の共有などで資料があった方が良い場合は簡単に作っておきます。あくまで非公式な資料なので凝りすぎないようにします
  • ステークホルダーの招集
    • これが非常に重要です。プロダクトオーナーはどのステークホルダーを呼ぶか判断して事前に調整しておいてください。頻繁に来てほしいステークホルダーの場合は最初に先の予定まで確保しておいて、不要な場合はキャンセル通知をするような運用が楽です

ステークホルダーへの質問(例)

スプリントレビューでは、ステークホルダーからの意見やフィードバックを貰います。 何も言わなくてもたくさんのフィードバックをくれる人と、そうでない人がいますので、状況を踏まえて定形的な質問パターンを使うのも良いでしょう。例えば以下のようなものです。

  • 気に入ったか?
  • いちばん気に入った箇所と、いちばん気に入らなかった箇所はなにか?
  • プロダクトを成功させるために変えたらよいことがあるか?
  • ビジョンはまだ有効か?
  • 機能不足、過剰な機能があるか?
  • 機能の間違いはないか?
  • 見た目の調整が必要か?
  • そう思うのはなぜか?

こんなスプリントレビューには気をつけよう

最後に、スプリントレビューがこのような状態だったら注意して改善しよう、というポイントをあげておきます。

  • 完成していないものをデモしている
    • 何も完成したものがない状態でも、なんとかスプリントレビューでフィードバックを貰いたいという気持ちは分かりますが、やめておいてください。動いていないもの、中途半端なものを見せるとフィードバックの質も下がりますし、スクラムチームに対する信頼もなくなります。スプリントレビューではスクラムチームが完成させたものを自慢するくらいの感じで進めるのが理想です
  • 完成したものと完成していないものをスプリントレビューで識別している
    • スプリントレビューは受け入れ確認の場ではありませんし、前述のとおり動かないもの、正しくないものを多くのステークホルダーに見せる意味もありません。なおステークホルダーが受け入れ可否を決めるわけではなく、それを決めるのはプロダクトオーナーです。もしステークホルダーの承認のようなものがないと完成に至らないのだとすると、ロールの割当が適切ではない可能性があります
  • スプリントレビューが進捗確認会議になっている
    • 全体の見通しの共有自体は重要であることは間違いありませんが、主目的はプロダクトの価値を高めるためにフィードバックを受けることです。もし進捗確認会議が必要なら、プロダクトオーナーとスクラムマスターあたりが別の会議を設けると良いと思います。
  • プロダクトオーナーがステークホルダーを招集していない
    • たくさんの時間とお金を使ったあとに、それがムダになるようなフィードバックを貰いたくないはずです。しかるべきステークホルダーを選んで適宜呼ぶようにしてください。もしスプリントレビューにステークホルダー不在の状況が続くのであれば、スクラムマスターは手を打つべきです
  • 最新の情報を使って今後の見通しなどの話し合いをしていない
    • ステークホルダーの一部、たとえばマーケティングや営業の人などは、そのプロダクトがいつリリースされそうかということに対して強い関心を持ちますし、彼らの仕事はリリースに対する依存関係があります。見通しを共有しないとビジネス全体から見た最適化ができなくなってしまうので、短時間で良いので今後の見通しを話すようにします

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック