3.4 Sprint Review Event & Stakeholder Feedback

3.4 Sprint Review Event & Stakeholder Feedback

The Sprint Review is the second-to-last event of the Sprint. It is timeboxed to a maximum of 4 hours for a one-month Sprint (and usually shorter for shorter Sprints, such as 2 hours for a two-week Sprint).

Far too often, traditional organizations mistakenly reduce the Sprint Review to a formal 'demo' or presentation. In authentic Scrum, the Sprint Review is an interactive working session where the Scrum Team and key stakeholders inspect the outcome of the Sprint (the Increment) and collaborate on what to do next.

---

Purpose and Dynamics of the Working Session

The primary objective of the Sprint Review is to inspect the Increment and adapt the Product Backlog. During this event, the Scrum Team and key stakeholders review what was accomplished in the Sprint, evaluate shifts in market conditions or business priorities, discuss release timelines and budgets, and collaborate on future valuable work.

+-----------------------------------------------------------------------------------+
|                                 SPRINT REVIEW FLOW                                |
|                                                                                   |
|  PARTICIPANTS: Scrum Team + Key Stakeholders (invited by Product Owner)          |
|  TIMEBOX: Max 4 hours for a 1-month Sprint (usually shorter)             |
|                                                                                   |
|  KEY ACTIVITIES:                                                                  |
|  1. PO explains what PBIs have been 'Done' and what has not been 'Done'.          |
|  2. Developers demonstrate the 'Done' working Increment & answer questions.       |
|  3. PO discusses Product Backlog status, projections, and market changes.         |
|  4. Group collaborates on next steps -> Output: REVISED PRODUCT BACKLOG.           |
+-----------------------------------------------------------------------------------+

Participants and Stakeholder Engagement

• The Scrum Team: The Product Owner, the Developers, and the Scrum Master.
• Key Stakeholders: Customers, internal business sponsors, domain experts, end-users, and operational managers invited specifically by the Product Owner.

Active stakeholder participation is essential for empirical process control. Stakeholders are not passive audience members watching a staged presentation; they actively test and interact with the functioning Increment, ask probing questions, and share insights regarding competitive pressures, user needs, and organizational strategy. Direct interaction between stakeholders and Developers yields qualitative, real-time feedback that static requirement documents or status emails can never capture.

---

Working Product Increments vs. Partial Progress

A core empirical principle enforced during the Sprint Review is that only completed work meeting the Definition of Done is part of the Increment and can be demonstrated.

+-----------------------------------------------------------------------------------+
|                           DEFINITION OF DONE FILTER                              |
|                                                                                   |
|   Selected PBIs ----> [ Developer Execution ] ----> Meets DoD?                    |
|                                                          |                        |
|                                    +---------------------+---------------------+  |
|                                    | YES                                 | NO     |
|                                    v                                     v        |
|                             INCLUDED IN INCREMENT                RETURN TO        |
|                             (Demonstrated at Review)             PRODUCT BACKLOG  |
+-----------------------------------------------------------------------------------+

• 'Done' Items: The Developers demonstrate items that fully satisfy the team's Definition of Done. Stakeholders interact directly with the working software or product feature.
• Undone / Partially Completed Items: Product Backlog items that are incomplete, partially coded, or fail to satisfy every criteria of the Definition of Done are strictly excluded from demonstration. They cannot be claimed as partial velocity or accepted into the Increment. Instead, they return immediately to the Product Backlog, where the Product Owner re-evaluates their priority for future Sprints.

Showing partial work or unintegrated code creates a false sense of progress, distorts transparency, and undermines the reliability of empirical feedback.

---

Key Elements of a Sprint Review Agenda

While the Scrum Team formats the session to best suit their product context, an effective Sprint Review systematically addresses four key elements:

1. Status Alignment: The Product Owner clarifies which Product Backlog items have been completed ('Done') and which items remain incomplete.
2. Demonstration & Technical Discussion: Developers present the 'Done' Increment, answer questions regarding technical implementation, explain challenges encountered, and solicit user feedback.
3. Business & Market Inspection: The Product Owner reviews overall product performance, current market trends, competitive shifts, budget projections, and target release dates based on actual team throughput toward the Product Goal.
4. Collaborative Backlog Adaptation: The entire group collaborates on what work is most valuable to pursue next, taking into account new opportunities, technical constraints, and stakeholder recommendations.

---

The Output: A Dynamic, Revised Product Backlog

The primary output of the Sprint Review is a revised Product Backlog. Rather than producing static meeting minutes or approval sign-off sheets, the event yields an updated, prioritized backlog that reflects fresh empirical data. This updated Product Backlog directly feeds into the upcoming Sprint Planning event, ensuring that the team continually pivots toward maximum business value.

---

Organizational Anti-Patterns to Avoid

On the PSM I exam and in real-world practice, several common anti-patterns degrade the effectiveness of the Sprint Review:

---

Timeboxing & Efficiency

The Sprint Review is timeboxed to a maximum of 4 hours for a one-month Sprint. For shorter Sprints, the timebox is usually shorter (e.g., 2 hours for a two-week Sprint).

Enforcing strict timeboxes prevents over-preparation and elaborate slide deck creation. The focus remains on raw, authentic product inspection rather than polished public relations presentations.

---

PSM I Exam Traps & Empirical Guidance

Exam Trap 1: "The Product Owner uses the Sprint Review event to inspect the work for the first time and formally approve or reject the Developers' work."

Scrum Truth: The Product Owner inspects work continuously throughout the Sprint as items are completed by Developers. Waiting until the Sprint Review to accept or reject work causes severe bottlenecks and violates continuous feedback.

Exam Trap 2: "The Developers show a PowerPoint presentation of unfinished UI wireframes to management because coding ran out of time."

Scrum Truth: A Sprint Review is focused on inspecting the working, functional Increment. Slide decks showing incomplete work provide false feedback loops and contradict empirical Scrum.

Exam Trap 3: "The Scrum Master conducts the Sprint Review to grade the performance of the Developers."

Scrum Truth: The Sprint Review is not a performance appraisal. It is a collaborative working session dedicated to product inspection and backlog adaptation.