【無料体験】Tech AcademyでPython機械学習入門コースが体験できる!今ならAmazonギフト券500円がもらえる!

【簡単解説】スプリントレビューの基本ルール・失敗例など

スクラムイベント

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

・スプリントレビューの基本ルール・やり方
・スプリントレビューの失敗例やノウハウ
を説明します。

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

この記事で読んでわかること!
  • スプリントレビューの概要が理解できる
  • スプリントレビューのやり方がわかる
  • より効果的なスプリントレビューが実践できる

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

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

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

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

スポンサーリンク

スプリントレビューとは?

agile-sprint-review

スプリントレビューとは、スプリントの成果をステークホルダーに披露し、フィードバックを得るイベントです。スプリントレビューはスクラムイベントの最後から2つ目に実施します。スプリントの成果(インクリメント)をデモすることで、フィードバックを引き出します。フィードバックを元に、プロダクトバックログの項目追加や優先順位の変更を検討します。

スプリントレビューが必要な理由

[目的]
スプリントレビューを通してフィードバックを得ることで、プロダクト価値を最適化し、今後何が必要で、どこまで実現できるかといったプロダクトの構想や戦略を練ることが目的です。

スプリントレビューを実施することで得られる具体的なメリットは以下です。
[メリット]
スプリント中に完成したもの、完成できなかったものの認識合わせができる
プロダクトがユーザーにとって価値のあるものになっているか第三者視点で確認できる
スプリントの結果やスプリント中の状況変化をステークホルダーとすり合わせリリース計画を見直せる
スプリントレビューでのフィードバックを元にプロダクト価値の最適化を図れる

とも坊

フィードバックに元に、PBIの優先順位は入れ替えて、価値を最大化できるようにするためにあるんだね。

スポンサーリンク

基本ルール

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

参加者/発言権

agile-sprint-review-participant
※ステークホルダーは、全員を呼ぶのではなく、必要な時に必要な人を呼ぶようにしましょう。
※スクラムマスターは、スプリントレビューが正しく運営されるようにファシリーテートは可能です。

やること
[プロダクトオーナー]
プロダクトバックログの受け入れ基準が達成できているか事前に確認する
・スプリントゴールやスプリントで完了したこと、完了できなかったことを説明できるように準備する
事前に参加者(特にステークホルダー)を決定し、会議招集をしておく
・プロダクトバックログを最新の状態に更新する
スプリントレビューのフィードバックを元にプロダクトバックログやリリース計画を見直す

[スクラムマスター]
・参加者にスプリントレビューの目的を理解してもらう
・スプリントレビューがスムーズに進むようにファシリテートする

[開発者]
・レビュー時のデモの準備をする
・ステークホルダーからのフィードバックをメモする

[ステークホルダー]
・利用者の視点でプロダクトをレビューし、フィードバックをする
・スプリント中に状況変化がある場合は共有する

[全員]
・スクラムチームとステークホルダーで、プロダクトをより良くするために話し合う
・今後のプロダクトゴールやリリース計画の認識を合わせる

作成物
プロダクトバックログ
フィードバックを元に、スプリントレビュー後プロダクトバックログの項目追加や優先順位の変更を検討します。

スプリントレビューのやり方

【基本的な流れ】
以下の順番に実施するとスムーズに進行できると思います。

事前準備:スクラムマスターはスプリントレビューの目的を参加者に説明する。

  1. スプリントレビューの参加者を紹介する。
  2. スプリントゴールを共有する。
  3. 本スプリントで実施したもの、実施できなかったものを共有する。
  4. デモの概要説明、実施。
  5. デモを通して、フィードバックやQAを実施する。
  6. スプリント中の状況変化などないか確認する。
  7. 直近のスプリントや今後のリリース計画を共有する。

スプリントレビューの具体例・イメージ

スクラムマスター

スプリント1のスプリントレビューをはじめます。よろしくお願いします。
はじめに、今回のスプリントレビューの参加者をPOからご紹介お願いします。

初回ですので、スクラムチームのメンバーから紹介します。
・・・開発者,SM,POを紹介する・・・
続いて、今回お集まりいただいているステークホルダーの方を紹介します。
・・・ステークホルダーを紹介する・・・

プロダクトオーナー

※スプリントレビューの参加者はプロダクトオーナーがインクリメントの内容に沿って必要なメンバーを調整します。POはスプリントレビュー冒頭で参加者がプロジェクトにどのように関わっているか簡単に共有するようにしましょう。関係性が見えるとその後のQAやフィードバックが活性化します。

スクラムマスター

参加者のご紹介ありがとうございます。
それでは、プロダクトオーナーから今回のスプリント結果の共有をお願いします。

今回のスプリントは「ユーザーが勤怠登録システムに社員番号でログインできるようにする」をスプリントゴールとして取り組みました。
スプリントの結果としては、計画13ptに対して、全てのプロダクトバックログアイテムが完了しています。
本日は、勤怠登録システムのTop画面に接続し、社員番号でログインするところをデモさせていただきますので、質問や要望などあれば、都度コメントお願いします。

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

それでは、デモを実践させていただきます。
本スプリントでは、開発環境に勤怠登録システムを作成しています。
URL:https://kintai.dev.management.jpをクリックすると、勤怠管理システムのTop画面が表示されます。
皆さまのPCからでも接続できるようになっておりますので、お試しください。

おっ、接続できた。
実際にシステムに触れるとイメージしやすくていいですね。
Topページの画面はシンプルでいいですね。文字のサイズや余白などレイアウト部分は少し気になるなー

ステークホルダーA
プロダクトオーナー

今回のスプリントでは、勤怠登録システムのイメージを持っていただけるように、画面レイアウトよりも機能作成を優先して作業しました。
細かい画面レイアウトの修正は後で実施しようと考えていますので、ぜひコメントください。

後で画面を見直す機会があるんですね。その時までに要望まとめておきますね。

ステークホルダーA
開発者A

ログイン時のIDは、社員番号になります。
今回は開発環境ですので、パスワードは固定にしてあります。
今後のスプリントで、初回ログイン時のパスワード設定機能を作成予定です。

システムごとにIDやパスワードが払い出されると管理が大変そう。
社内PCも社員番号でログインしているので、その時のパスワードと共通化できないでしょうか?

ステークホルダーA
プロダクトオーナー

確かにそうですね。
PCログイン時の認証機能が社内公開されているか確認してみます!

認証機能が利用できるなら開発工数も削減できるので、APIが公開されているなら是非利用したいです。

開発者A
ステークホルダーA

開発の進捗は計画通りだったみたいだけど、今後の見通しやリリース計画はどんな感じですか?

まだ始まったばかりですので確度は低いですが、今回のベロシティで考えるとスプリント10でMVPが完了する計画です。
今後スプリントを繰り返すことで計画の制度やベロシティは向上していく想定です。
逆に質問ですが、スプリント中に状況変化などありましたか?

プロダクトオーナー
ステークホルダーA

実は企画内で勤怠登録だけでなく、勤務場所の登録もできないかって話が出ているんですよね。
リモートワークも増えたので、会社への出社率やサテライトオフィスの利用率などを測定したいらしいんだよね。
まだ決まっていないんだけど、決まったらこの場で共有すればいいのかな?

プロダクトバックログの優先順位に影響がある場合は、スプリントレビューまで待たずに私に適宜相談してもらえればOKです。

プロダクトオーナー
ステークホルダーA

了解です。決まったら直ぐに連絡します。
機能の優先度は迷っている部分もあるため、一緒に相談させてください。

もちろん、コミュニケーションを密に取りながら、作業の優先度やリリース計画を見直しましょう!

プロダクトオーナー

スプリントレビューのよくある失敗例

スプリントレビューにおいて、以下の失敗例に当てはまっているものがないか確認しましょう。

・プロダクトオーナーがスプリントで完了したもの、完了できなかったものを把握していない
・DoD(完成の定義)を満たしていない
・POがAC(受け入れ基準)を満たしているか確認できていない
・スプリントの結果やベロシティを参加者に共有できていない
・開発者がスプリントで作成したものをデモでステークホルダーへ披露することができない
・ステークホルダーがレビューに関わろうとしない
・スプリント結果の報告のみとなっていて、プロダクトに対するフィードバックが出てこない
・今後の見通しやリリース計画などの話し合いができていない

スプリントレビューで活かせるノウハウ

スプリントレビューの効果を最大化するための取り組みを共有します。
みなさんのチームで取り入れられそうなものがあれば、是非チャレンジしてみてください。

レビュー前日にプロダクトオーナーと開発者でスプリントの結果をすり合わせる
デモする内容や手順を予め準備し、リハーサルをしておく
外部システムを利用している場合はレビュー日時を共有しリリース作業等を控えてもらう
フィードバックをメモする担当者を決めておく
ステークホルダーからフィードバックが引き出せない場合は、事前に質問を準備しておく
 プロダクトビジョンに変更はないか?
 機能不足 or 不要な機能はないか?
 画面UIで気になるところはないか?(フォントサイズ、レイアウト、画面遷移など)
プロダクトオーナーは次のスプリントプラニンング前にフィードバックをプロダクトバックログに反映する時間を予め設けておく

まとめ

  • スプリントレビューは、スプリントの成果をステークホルダーに披露し、フィードバックを得るためのイベント
  • プロダクト価値を最適化し、プロダクトの今後の戦略を練ることが目的
  • デモを通して、ステークホルダーからフィードバックをもらう
  • プロダクトの現状と今後の見通し(リリース時期)に関して話し合う
  • フィードバックや状況の変化をプロダクトバックログを適応する

参考資料

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

コメント

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