「スプリントレビュー」でやることは何ですか?と聞かれて、具体的な内容をイメージできる人は少ないと思います。
単なる作業報告になってると感じることがよくあるんですよね。。。
スプリントレビューの基本ルールや具体的な進め方を解説するよ!
・スクラムイベントにおける「スプリントレビュー」とは何かを理解できる
・スプリントレビューの基本的なやり方がわかる
・失敗例やノウハウを知ることができ、より効果的なスプリントレビューが実施できるようになる
スプリントのスケジュールでいうと以下の赤枠部分です。
スクラムイベント全体像がわからないからは、先に以下の記事をご確認ください。
PBL:プロダクトバックログ
PBI:プロダクトバックログアイテム
PO:プロダクトオーナー
SM:スクラムマスター
DoD:完成の定義
AC:受け入れ基準(Acceptance Criteria)
スプリントレビューとは?
スプリントレビューとは、スプリントの成果をステークホルダーに披露し、フィードバックを得るイベントです。
スプリントレビューはスクラムイベントの最後から2つ目に実施します。
スプリントレビューでは、スプリントの成果(インクリメント)をデモすることで、フィードバックを引き出し、フィードバックを元に、プロダクトバックログの項目追加や優先順位の変更を検討します。
スプリントレビューが必要な理由
[目的]
スプリントレビューを通してフィードバックを得ることで、プロダクト価値を最適化し、今後何が必要で、どこまで実現できるかといったプロダクトの構想や戦略を練ることが目的です。
[メリット]
スプリントレビューを実施することで得られる具体的なメリットは以下です。
・スプリント中に完成したもの、完成できなかったものの認識合わせができる
・プロダクトがユーザーにとって価値のあるものになっているか第三者視点で確認できる
・スプリントの結果やスプリント中の状況変化をステークホルダーとすり合わせリリース計画を見直せる
・スプリントレビューでのフィードバックを元にプロダクト価値の最適化を図れる
成果を披露すること自体が目的ではなく、プロダクトの価値や今後の戦略を考えることが大切だよ
基本ルール
[タイムボックス]
以下の時間を目安に設定する。
・1週間スプリントの場合:1時間
・2週間スプリントの場合:2時間
※スクラムガイドでは、1ヶ月スプリントで最大4時間とされています。
[参加者/発言権]
※ステークホルダーは、全員を呼ぶのではなく、必要な時に必要な人を呼ぶようにしましょう。
※スクラムマスターは、スプリントレビューが正しく運営されるようにファシリーテートは可能です。
[やること]
プロダクトオーナー
・プロダクトバックログの受け入れ基準が達成できているか事前に確認する
・スプリントゴールやスプリントで完了したこと、完了できなかったことを説明できるように準備する
・事前に参加者(特にステークホルダー)を決定し、会議招集をしておく
・プロダクトバックログを最新の状態に更新する
・スプリントレビューのフィードバックを元にプロダクトバックログやリリース計画を見直す
開発者
・レビュー時のデモの準備をする
・ステークホルダーからのフィードバックをメモする
スクラムマスター
・参加者にスプリントレビューの目的を理解してもらう
・スプリントレビューがスムーズに進むようにファシリテートする
ステータクホルダー
・利用者の視点でプロダクトをレビューし、フィードバックをする
・スプリント中に状況変化がある場合は共有する
[作成物]
・プロダクトバックログ
プロダクトオーナーは、スプリントレビュー後に、フィードバックの内容をプロダクトバックログに反映し、優先順位の見直しを実施する。
参加者全員が、プロダクトをより良くするためにこの場に集まっていることを忘れないようにしましょう!
今後のプロダクトゴールやリリース計画の認識合わせを行うことも大切です。
スプリントレビューのやり方
[基本的な流れ]
以下の順番に実施するとスムーズに進行できると思います。
- スプリントレビューの参加者を紹介する。
- スプリントゴールを共有する。
- 本スプリントで実施したもの、実施できなかったものを共有する。
- デモの概要説明、実施。
- デモを通して、フィードバックやQAを実施する。
- スプリント中の状況変化などないか確認する。
- 直近のスプリントや今後のリリース計画を共有する。
スプリントレビューは目的を理解してもらうことが非常に重要です。慣れてくるまでは、スクラムマスターがスプリントレビューの開始時に目的を参加者に説明し、ファシリテートをサポートしてあげましょう!
進め方のイメージ・具体例
慣れるまではスクラムマスターがファシリテートしましょう。
スプリントレビューの流れがわかってきたら、開発者がファシリテートを担当するのがおすすめです。
(POはステークホルダーからフィードバックを引き出すのに注力してもらいたいため。)
スプリント1のスプリントレビューを始めます。
まず、効果的なレビューにするためには、私の方からスプリントレビューの目的を説明させていただきます。
スプリントレビューの目的を共有
(全員に目的が浸透してきたらスキップしてもOKです)
では、プロダクトオーナーから本スプリントのスプリントゴールとインクメントの共有をお願いします。
本スプリントのスプリントゴールは「ユーザーが勤怠登録システムに社員番号でログインできるようにする」です。
そのため、今回のスプリントレビューの参加者は、エンドユーザーとの接点が多いサポートセンターの方々を招集させていただいております。
参加者はスプリントゴールやインクリメントの内容に沿って必要なメンバーをPOが調整します。
また、レビューの冒頭で参加者がプロジェクトにどのように関わっているか簡単に共有するようにしましょう。
関係性が見えるとその後のQAやフィードバックが活性化します。
本スプリントは、以下のようになっています。
計画:13pt
Done:10pt
Undone:3pt
想定していたライブラリの互換性が悪く代替案を検討していた影響で予定していたPBLが完了しませんでした。
スプリントゴールに対して、何が完了し、何が完了しなかったかを参加者に伝えるようにしましょう!
実際に完了した内容のデモを披露させていただきます。
システムの利用方法などを共有させていただきますので、デモの後に実際にみなさんにも触っていただきフィードバックをいただければと思います。
開発者が事前に準備していたデモを披露する
デモは以上となります。
みなさんのチャットに接続用のURLとアカウントをご連絡させていただきました。実際に触っていただき、何かお気づきの点があればコメントよろしくお願いします。
実際にステークホルダーにプロダクトを触ってもらう
おっ、接続できた。
実際にシステムに触れるとイメージしやすくていいですね。
ステークホルダーはデモの内容で気になった点や実際にプロダクトを触ってみた時に感じた気づきを共有します
Topページの画面はシンプルでいいですね。文字のサイズや余白などレイアウト部分は少し気になるなー
今回のスプリントでは、イメージを掴んでいただくために、画面レイアウトの詳細よりも、画面遷移の動きや機能を重視しました。
細かい修正は、スプリントの後半で調整できるように予定しています。
後で画面を見直す機会があるんですね。その時までに要望まとめておきますね。
最後に今後へ向けて全員で話し合います
フィードバックもひと段落したようですので、今後の計画やリリーススケジュールに関して、POより共有お願いします。
次のスプリントでは○○の価値を提供するために××の機能の作成に取り掛かろうと考えています。
また、現在のベロシティのまま行くと、初回リリースは○月くらいになりそうてす。
先ほどのコメントした画面レイアウトなどの修正はいつ頃になりそうですか?
初回リリース前の2スプリントをレイアウト修正にあてる想定ですので、△月ごろとなります。
この後、計画通りに進んだ場合は、最終的な開発費はどのくらいになりそうですか?
1スプリントあたりの体制維持にかかる費用が250万円です。
順調に行くと全10スプリントとなるので、2500万円になる見込みです。
想定よりも少し高いなー。予算管理部門と事前に調整しておくよ。
もう少し効率化や簡略化できないか検討はしてみて欲しい。
ありがとうございます。
必要費用の見込みに関しては、レビューの場で都度共有させていただきます。
実際に修正が入ったところのみに試験をフォーカスするなど、削減できそうな点がないかは開発者でも検討してみます。
よろしくお願いします。
開発費用を優先することで、要件の調整が必要な場合は別途相談させてもらえればと思います。
コミュニケーションを密に取りながら、必要に応じて要件やリリース計画の見直しをさせていただければと思います。
POは、レビューで出たフィードバックを元にプロダクトバックログや今後の計画をアップデートします
よくある失敗例・アンチパターン
みなさんのチームのスプリントレビューにおいて、以下の失敗例に当てはまっているものがないか確認しましょう。
[失敗例]
・プロダクトオーナーがスプリントで完了したもの、完了できなかったものを把握していない
・DoD(完成の定義)を満たしていない
・POがAC(受け入れ基準)を満たしているか確認できていない
・スプリントの結果やベロシティを参加者に共有できていない
・開発者がスプリントで作成したものをデモでステークホルダーへ披露することができない
・ステークホルダーがレビューに関わろうとしない
・スプリント結果の報告のみとなっていて、プロダクトに対するフィードバックが出てこない
・今後の見通しやリリース計画などの話し合いができていない
現場で活かせるノウハウ
スプリントレビューの効果を最大化するための取り組みを共有します。
みなさんのチームで取り入れられそうなものがあれば、是非チャレンジしてみてください。
[ノウハウ]
・レビュー前日にプロダクトオーナーと開発者でスプリントの結果をすり合わせる
・デモする内容や手順を予め準備し、リハーサルをしておく
・外部システムを利用している場合はレビュー日時を共有しリリース作業等を控えてもらう
・フィードバックをメモする担当者を決めておく
・ステークホルダーからフィードバックが引き出せない場合は、事前に質問を準備しておく
プロダクトビジョンに変更はないか?
機能不足 or 不要な機能はないか?
画面UIで気になるところはないか?(フォントサイズ、レイアウト、画面遷移など)
・プロダクトオーナーは次のスプリントプラニンング前にフィードバックをプロダクトバックログに反映する時間を予め設けておく
「スプリントレビュー」まとめ
[ポイント]
・スプリントレビューは、スプリントの成果をステークホルダーに披露し、フィードバックを得るためのイベント
・プロダクト価値を最適化し、プロダクトの今後の戦略を練ることが目的
・デモを通して、ステークホルダーからフィードバックをもらう
・プロダクトの現状と今後の見通し(リリース時期)に関して話し合う
・フィードバックや状況の変化をプロダクトバックログを適応する
参考資料
・いちばんやさしいアジャイル開発の教本
・Ryuzen.com
スクラム関連のおすすめ記事
スクラム開発をもう少し勉強したい!と思った方は、以下の記事がおすすめです。
実際に私が読んだ本の中で「絶対に損しない」初心者が読みやすい本をピックアップしてレビューしています。
教本選びのご参考になれば幸いです。
本を読んでいる暇がない!活字は少し苦手。。。という方は、動画教材がおすすめです。
通勤中や就寝前などに必要なセクションのみ選択して学習できるため学習効率が非常に高いです。
また、近年アジャイル人材の需要が高まっています。
アジャイル人材の需要や年収などを以下の記事にまとめていますので、学習のモチベーション維持にお役立てください。
コメント