コンテンツにスキップ
Scrum Knowledge Graph

スプリントレビュー (Sprint Review)

概要

Section titled “概要”

スプリントレビューは、スプリント終了時に開催される定例イベントであり、完成したインクリメントをステークホルダーとともに検査・検証し、プロダクトバックログの調整や次期計画の適応を図る協働のワーキングセッションである。単なる一方的なデモにとどまらず、技術計画や機能要件、期待される品質基準の達成度を評価するとともに、提供価値や残存する不確実性を検証し、関係者間で今後の方向性を合意・決定する協調学習の場として機能する。ステークホルダーが成果物を直接操作・検証してフィードバックを交わすことで、プロダクト価値の最大化やチームの動機づけを促し、次期スプリントへの円滑な引き継ぎを実現する。タイムボックスは1か月のスプリントで最大4時間である。大規模環境では集約・統合されたレビューが実施される一方、イベントの省略や形骸化といった反パターンの回避が重視される。

詳細

Section titled “詳細”

スプリントレビューは、作成したインクリメントを共有してフィードバックを得るためのスプリント終了前の定例イベントとされ、ステークホルダーとの協働を深めることでチームの応答性や満足度の向上に大きく寄与するとされる[1][2]。スプリントレビューで、納品された成果物の品質を検討した事例も報告されている[3]。大規模組織や複数チーム環境への適用において、個別チームごとのレビューがチーム・オブ・チームズ全体の統合レビューイベントに置き換わる、あるいは集約される傾向がある[4]。LeSSなどのスケーリング手法においても、全チームが共通の成果物を対象とする共有スプリントレビューが実施される[5]。Nexusでは個別のレビューを置き換える形で「Nexusスプリントレビュー」が実施され統合インクリメントを検査するが[6]、ここでは個別チームのレビューを実施せず、Nexus全体（チーム・オブ・チームズ）とステークホルダーが参加する単一のレビューイベントに統合される形をとる[4]。SAFeにおいてはチーム間の同期・レビューイベントとして「システムデモ（System Demo）」が位置づけられる[4]。Scrum@Scaleでは顧客ニーズとの整合性を図り、「What（作るもの／作ったもの）」という観点で成果物を検証する機会として位置づけられている[7]。

タイムボックスは1か月間（4週間）のスプリントの場合、最大で4時間（4時間を上限）であり、より短いスプリントではそれ以下の短時間で実施される[8]。このタイムボックスの規定は、各版のスクラムガイドをはじめとする各種文献・ガイドラインに共通して明記されている[9][10][11][12][13][8][14][15][16]。

参加者とファシリテーション：プロダクトオーナー、スクラムチーム（開発チーム）、スクラムマスター、およびプロダクトオーナーによって招待された主要なステークホルダー（顧客等）が協働して参加する[10][11][12][14][15][17][18][1]。さらに、障がいを持つ指導者や学生などのエンドユーザーをステークホルダーとして直接招待し、検証や即時フィードバック収集に関与させる事例も示されている[19]。Nexusスプリントレビューにおいても、主要なステークホルダーが参加して統合インクリメント全体に対するフィードバックを提供する[6]。Scrum@Scaleにおけるスケールされたスプリントレビューでは、チーフプロダクトオーナー（CPO）が率いるプロダクトオーナーチームを中心にファシリテーションを担当する[7]。

実施内容：作成された「完了（完成）」インクリメントや動くソフトウェアプロトタイプのデモンストレーション、要求仕様や受け入れ条件への適合性の評価[15]、市場動向、プロダクトゴールに向けた進捗の共有および検査が行われる[8][16][15][19]。単なる一方的な口頭やスライドによるプレゼンテーションではなく、動くプロダクトをステークホルダーが直接操作・評価するインタラクティブな形式は効果的とされる[18]。実際に動作するプロダクトインクリメントを中心とした評価・検査を進行する[14][15]。スプリント内で生成されたインクリメントがステークホルダーに提供する価値を評価するとともに、開発を通じて残存した前提条件、仮定、未解決の不確実性を明確にし、次のアクションを決定する[20][21]。提示されるインクリメントは、アウトプット完成の定義だけでなくアウトカム完成の定義を満たしたものであり、最新の成果指標とともに提示される[16][20]。プロダクトオーナーは「完了（完成）」した項目と未完成の項目を識別・説明し、現在のプロダクトバックログ、ベロシティや過去の進捗に基づく完了予定日の予測、今後の進捗予測やプロダクトバックログ全体の調整を示す[9][10][11][12][13][16]。スクラムチーム（開発チーム）は「完成」した成果物をデモンストレーションし、参加者からの質問へ答えるとともに、スプリント中にうまくいったことや直面した問題とその解決策について説明・議論する[10][11][12][13][22]。グループ全体で市場や組織の環境変化、利用状況、予算、成果、学び、トレードオフ、新しく生まれた機会やアイデアについて双方向で協議・検査する[10][11][12][8][16][14][20]。単なるプレゼンテーションではなくスクラムチームとステークホルダーが協働する場として機能する[8][17][9][10][12][11][23][13][16][18]。レビューでは、成果物や動くソフトウェアを披露・デモしてフィードバックを収集する[2][21][19]。

得られたフィードバックや洞察[16]・評価結果[15]・不具合の確認や今後の改善点[2]・新たに得られた発見や市場環境の変化[18]・調整決定事項やプロジェクト全体の品質向上への反映[1]・エンドユーザーからの直接フィードバックの反映[19]・市場や組織などの外部環境の変化[14]・プロダクトゴールの進捗状況[6][8]・フロー分析結果といった多様な要素が検査の対象となる[17]。これらに基づき、プロダクトオーナーを中心に改訂・再定義されたプロダクトバックログ（優先順位や内容の調整を含む）および今後の開発戦略が成果として作成・適応される[10][11][12][13][8][24][14][15][17][2][19][18]。獲得されたフィードバックはプロダクトオーナーによって追跡管理される[21]。Nexusスプリントレビューにおいても、得られたフィードバックに基づき今後のアクションやプロダクトバックログの調整について協議が行われる[6][7]。さらに、検査と学習の結果に基づき、プロダクトバックログのみならずプロダクトゴールや「アウトカム完成の定義」も更新・適応される[16][2]。これが次のスプリント計画（スプリントプランニング）に向けた有用なインプット（入力）となる[10][11]。通常のスクラムではチームとステークホルダーが合意形成を行ってスプリントの成果や次のステップを決定するが、LeSSではプロダクトオーナーがレビュー内容を事前に決定してチームやステークホルダーに公開する形をとる場合がある[4]。また、SAFeのSystem Demoでは、その内容や参加者がチームとステークホルダーの合意によって決定される[4]。そして、各反復の終了時に潜在的に機能する製品インクリメントを内部および外部のステークホルダーへ実演・提示し、多様な視点から直接的かつ明確なフィードバックを受け取ることは、仕事の資源である「タスクからのフィードバック」を強化し、チームが自身の役割や組織目標への貢献度を客観的に認識することを可能にして、有能感の充足と仕事への動機づけを促進する効果も持つとされる[25]。

テイラリング、反パターン、および実施環境の影響：スプリントレビューは最も頻繁にテイラリング（改変・調整）が行われるプラクティスの1つとされる[26]。標準的な定義に対し、実際のプロジェクトでは、イベントの完全な省略・代替（イベントを開催せずQAチームのみで評価する形態を含む）[26]・開発チームを除外してスクラムマスターやプロジェクトマネージャー、顧客のみで実施するケース[26]・開発者向けの内部レビューと顧客を含む外部レビューに分ける「複数回開催（2段階実施）」[26]・顧客不在で外部ステークホルダーのみを対象とする形式[26]といった運用パターンが報告されている。このようなイベントの未実施や顧客不在といったテイラリングを行うと適時なフィードバックの欠如を招き、開発後半や製品リリース後において大規模な手戻りや変更の発生リスクが高まる[26]。また、ソフトウェア開発組織における反パターン（アンチパターン）の調査では、「スプリントがデモンストレーションで終わらない」事象は、スプリント完了に関する反パターンの中で唯一、36.8%の回答者が「頻繁に」「常に」発生すると答えた[27]。表IXの重み付けスコアは38.10%（満点168に対する割合で、組織の割合ではない）である[27]。さらに、「誤った対象者へのデモンストレーション」（24.40%）や「ステークホルダーの関心不足によるフィードバックの遅延」（30.95%）も調査された[27]。数字は表IXの重み付けスコア（満点168に対する割合）で、スプリント完了に関する反パターンはほとんどの組織で主要な問題とはなっていない[27]。加えて、リモートワーク環境における実施では、対面と比較して十分なフィードバックの獲得や濃密な相互作用の維持は困難になる傾向が観察される[21]。さらに、大規模アジャイル環境においては、会議の頻度や長さが問題視されることがあり、スプリントレビューを含む多数の会議の頻発が開発に専念する時間を奪う過剰な儀式と捉えられる負担感が生じるリスクが報告されている一方、ステークホルダーとの認識合わせや整合性の確保において不可欠な役割を担っているとされる[22]。

スプリントレビューはスプリントの終わりに開催されるタイムボックスが設けられたミーティングであり、チームメンバーが完成したインクリメンタルな動くモデルを提示する[28]。

LeSSにおけるスプリントレビューバザールは、チームが自らの作業を顧客価値と関連付ける実践の機会を提供し得る[29]。Covid-DI チームのスプリントレビューの開催は、オフィスの毎スプリントから、リモートの 2〜3 スプリントごとへ減り、のちに不定期となった（1 社の Action Research でのスクラムマスターの報告）[30]。多国籍電気通信企業 Ericsson の 2 ユニット（15 チーム、27 人へのインタビュー）では、スプリントレビューはどのチームでも個別には実施されておらず、ユニット会議の中で開催されていた[31]。

新メンバーのオンボーディングを調べた英国の大学 IT 部門の単一ケース研究では、スプリントレビューで得られたフィードバックは、技術的な事項に関するものだった[32]。

ニュージーランドの IT 中心企業の小売部門の事例（1 組織、アジャイル専門職 9 人へのインタビュー）では、一部のチームがスプリントレビューを経営幹部に好印象を与えるためのショーケースとして使い、マネージャー向けとチーム内の「本物の」レビューの 2 つを実施した[33]。

スプリントレビューは、各スプリントの終わりにステークホルダーとともにプロダクトを検査し、改善に向けたフィードバックを収集するイベントである[34]。

STEM-EFでは、スプリント結果の分析とインクリメントのデモンストレーションを通じて、ステークホルダーからの批判的フィードバックに対する感情管理や協調的な交渉の実践を評価する枠組みを提示している[35]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Sprint Review Scrum Event
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

Process Constraints (プロセス制約)

Section titled “Process Constraints (プロセス制約)”

SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • E2 [警告] (SprintReview): スプリントレビューには、少なくとも1名のステークホルダーが参加(participatesIn)するべきです。フィードバックループが機能していない可能性があります（Verwijs & Russo, 2022）。

脚注

Section titled “脚注”

  1. Agile Software Development with Secure and Scrum-Centric Approach — 「スクラムにおけるスプリントレビューでのフィードバックは、プロジェクトバックログを調整し、プロジェクトを改善するのに役立ちます。」（原文: “Feedback in Sprint Reviews in Scrum helps adapt the project backlog and improve the project.”）（訳）（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  2. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「スクラムチームはスプリントレビューミーティングを開催し、スプリント期間中の成果を披露します。」（原文: “The Scrum team will hold a Sprint review meeting to show their results during the Sprint.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  3. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「スプリントレビューのセレモニーでは、チームは納品されたパッケージの品質について議論し、それに続いてスプリントレトロスペクティブで、ArchHypoへの適応を含め、プロセスがどのように実行されたかを議論した。」（訳）（ライセンス: CC BY 4.0） ↩

  4. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「例えば、Nexusスプリントレビューは個々のスクラムチームのスプリントレビューを置き換えるものであり、Nexus全体（チーム・オブ・チームズ）およびステークホルダーが参加者となる。」（原文: “Nexus Sprint Review, for instance, replaces individual Scrum Team sprint reviews, having the whole Nexus (team of teams) and stakeholders as participants.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  5. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches — 「各スプリントは共有のスプリントプランニングで始まり、共有のスプリントレビューとスプリントレトロスペクティブで終了する。」（訳）（ライセンス: CC BY 4.0） ↩

  6. Nexus Guide — 「Nexus スプリントレビューは、スプリントの最後に開催される。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  7. Scrum@Scale Guide — 「スケールされたスプリントレビューとバックログリファインメントは、チーフプロダクトオーナー(CPO)が率いるプロダクトオーナーチームがファシリテートする。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  8. Scrum Guide 2020 — 「スプリントレビューはワーキングセッションであり、スクラムチームは スプリントレビューをプレゼンテーションだけに限定しないようにする。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  9. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3

  10. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  11. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  12. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  13. Scrum Guide 2017 — 「スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバック ログの適応を行うものである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  14. Scrum Guide (LeSS Version) — 「スプリントレビューはスプリントの最後から2番目のイベントであり、1ヶ月のスプリントにおけるタイムボックスは最大4時間である。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  15. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development — 「スクラムは、開発チームとプロダクトオーナー（PO）が参加してスプリントの計画と評価を行うミーティングであるスプリントレビューを定めています。」（原文: “Scrum prescribes sprint reviews, which are meetings involving the development team and the Product Owner (PO) to plan and evaluate sprints, …”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  16. Scrum Guide Expansion Pack — 「スプリントレビューは、プロダクトゴール、プロダクトバックログ、スプリントゴール、 学び、インクリメント、ステークホルダーの期待と制約、結果からのフィードバック(結 果フィードバック)、副次的な影響、プロダクトの進捗状況、市場動向、さらに、将来を 見据えた事項 ̶̶ 新たに生まれたアイデアや機会、次に取り得る可能性のあるステップ など ̶̶ について検査する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  17. Scrum: An Agile Software Development Process and Metrics — 「スプリントレビューがプロダクトのレビューであるのに対し、スプリントレトロスペクティブはプロセスのレビューです。」（原文: “The Sprint Review is the Product Review and Sprint Retrospection is the Process Review.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  18. A Theory of Scrum Team Effectiveness — 「スプリントレビューの質（Sprint Review Quality）：スプリントレビューは、ステークホルダーからフィードバックを収集し、調整を特定するためのスクラムにおける公式イベントです [135]。」（原文: “The Sprint Review is a formal event in Scrum where feedback is gathered from stakeholders and adjustments are identified [135].”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  19. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  20. Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「このサイクルは、既存のスクラムイベントを通じて運用できます。リファインメントによって不確実性を特定し、エビデンスの必要性を準備できます。スプリントプランニングでは、選択されたストーリーが十分に理解され実現可能であることを検証できます。デイリースクラムでは、チーム全体の進捗とブロッカーを調整できます。スプリントレビューでは、提供された価値と残された前提条件を評価できます。そしてレトロスペクティブでは、コラボレーション、トレーサビリティ、プロトタイプ、フローのポリシーが学習を支援したかどうかを評価できます。」（原文: “This cycle can operate through existing Scrum events. Refinement can identify uncertainty and prepare evidence needs; Sprint Planning can verify that the selected story is sufficiently understood and feasible; the Daily Scrum can coordinate collective progress and blockers; the Sprint Review can evaluate delivered value and remaining assumptions; and the retrospective can assess whether the collaboration, traceability, prototype, and flow policies supported learning.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  21. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  22. Systematic Literature Review Report on the Challenges of Agile Scrum — 「デイリースクラムミーティング、デイリースクラムオブスクラムミーティング、スプリントレビューミーティング、スプリントプランニングミーティングがアジャイルスクラムのセレモニーを構成する。」（原文: “Daily Scrum Meeting, the Daily Scrum of Scrums Meetings, the Sprint Review Meetings and the Sprint Planning Meetings constitute Agile Scrum ceremonies.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  23. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） ↩

  24. Kanban Guide for Scrum Teams 2021（ライセンス: CC BY-SA 4.0） ↩

  25. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩

  26. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  27. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  28. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「これはタイムボックス（時間制限）が設けられたミーティングであり、チームメンバーが完成したインクリメンタルな動くモデルを提示します。」（訳）（ライセンス: CC BY 4.0） ↩

  29. Requirements engineering challenges and practices in large-scale agile system development — 「LeSS はスプリントレビュー・バザール（Sprint review bazaar）を提供しており (Larman and Vodde, 2016)、これはチームが自分たちの作業を顧客価値と関連付ける実践を行う機会を提供し得る。」（原文: “LeSS offers Sprintreview bazars (Larman and Vodde, 2016), which might offer teams an opportunity to practice relating their work to customervalue.”）（訳）（ライセンス: CC BY 4.0） ↩

  30. Overcoming Challenges of Virtual Scrum Teams: Lessons Learned Through an Action Research Study — 「リモートモードでは、このミーティングは2〜3スプリントごとに開催されるのが通例となり、時間の経過とともにその規則性は薄れ、たまに開催される程度にまで減少した。対照的に、オフィスではスプリントレビューは毎スプリント開催され、特定のスプリントで提示可能なインクリメントが何も生み出されなかった場合にのみ中止されるなど、キャンセルされることは滅多になかった。」（原文: “In the remote mode, the meeting used to take place every two to three sprints, and over time this regularity has diminished to an occasional occurrence. In contrast, at the office Sprint Review was held every sprint, and it was seldom canceled – only if a particular sprint did not produce any presentable Increment.”）（訳）（ライセンス: CC BY 4.0） ↩

  31. Hybrid Work in Agile Software Development: Recurring Meetings — 「スプリントレビューはどのチームでも個別には実施されていなかった。前述のユニット会議の中で開催されていたためである。」（訳）（ライセンス: CC BY 4.0） ↩

  32. Onboarding: How Newcomers Integrate into an Agile Project Team — 「スプリントレビューにおけるフィードバックは、技術的な事項に関連していた。」（訳）（ライセンス: CC BY 4.0） ↩

  33. An exploratory study of sustaining organisational agility — 「チームの成果物に対する本物のフィードバックを提供するという本来の目的を果たす代わりに、それらのレビューは経営幹部に好印象を与えるためのショーケースとして利用されていた。その結果、チームはマネージャー向けと、チーム内での「本物の」レビューという2つのスプリントレビューを実施せざるを得なくなり、余分な作業と時間を生み出した。」（原文: “Instead of serving their true purpose, which was to provide authentic feedback on the team’s work, the reviews were used as showcases to impress senior leaders. As a result, the teams had to conduct two sprint reviews: one for managers and another ‘real’ review among the team, creating extra work and time.”）（訳）（ライセンス: CC BY 4.0） ↩

  34. Scrum: A Systematic Literature Review — 「各スプリントサイクルの終わりにはスプリントレビューが行われ、フィードバックを得てプロダクトの分析を行うために、顧客を含むステークホルダーおよびプロジェクトチームによってプロダクトが検査される。」（原文: “At the end of each sprint cycle, there is a sprint review, where products are inspected by stakeholders, including customers, and the project team, to get feedback and conduct product analysis.”）（訳）（ライセンス: CC BY 4.0） ↩

  35. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「各項目は、意図された行動の焦点に基づき、スクラムイベント（スプリントプランニング、デイリースクラム、スプリントレビュー、またはスプリントレトロスペクティブ）に明示的にマッピングされた。」（原文: “Each item was explicitly mapped to a Scrum event—Sprint Planning, Daily Scrum, Sprint Review, or Sprint Retrospective—based on its intended behavioral focus.”）（訳）（ライセンス: CC BY 4.0） ↩