The Sprint Review That Isn't
A Scrum Master observes a team's Sprint Review. The meeting runs 90 minutes. The first 70 minutes are a slide deck walking stakeholders through what the team did, followed by a 15-minute demo of a feature that was completed two Sprints ago because 'it's more polished.' The final 5 minutes are Q&A. Eight stakeholders attend, including a compliance officer whose sign-off is required for release. The Product Owner presents the slides; the Developers sit silently at the back. The compliance officer leaves after 40 minutes without asking a question. After the Review, the team's manager tells the Scrum Master that the Review 'went well - no one complained.' The next Sprint's backlog is unchanged from what the PO had already written before the Review.
1. Evaluate this Sprint Review against its purpose in Scrum. What is the event supposed to accomplish, and which elements are missing?
Read the worked answer
The Sprint Review exists so the Scrum Team and stakeholders inspect the outcome of the Sprint and collaborate on what to do next. It is a working session, not a status report. The output is an adapted Product Backlog and shared understanding of the environment.
What's missing or inverted here:
- Inspection of the Increment. The demo shows a two-Sprint-old feature, so stakeholders are not inspecting what was actually built this Sprint. The Increment is the object of inspection.
- Collaboration on next steps. The backlog is unchanged afterward - the defining output of the Review did not occur. Q&A for 5 minutes is not collaboration.
- The right people. The compliance officer, whose sign-off gates release, left early and never engaged. The people whose input would change the backlog were not in the conversation.
- The Developers' voice. The people who built the Increment are silent at the back; the PO narrates. The team that can answer 'how' and 'what's the risk' is not participating.
- Focus on the Sprint Goal. No mention of whether the Sprint Goal was met; slides about activity are not the same as inspecting the outcome against the goal.
The manager's 'no one complained' is a false positive: silence is the symptom, not the success criterion.
2. Redesign this Sprint Review. Specify duration, who presents, the agenda with timeboxes, and how the compliance officer's constraint is handled.
Read the worked answer
Duration: timebox to 60 minutes (the team's Sprint is presumably 2-4 weeks; 90 minutes of slides is not inspection).
Who presents: the Developers demonstrate the Increment; the Product Owner frames the Sprint Goal and leads the discussion of what's next. The Scrum Master facilitates and protects the timebox.
Agenda (60 min)
- 5 min - PO states the Sprint Goal and whether it was met, and the product goal context.
- 20 min - Developers demo this Sprint's Increment on a working environment, including known limitations and open risks. No slides of activity.
- 10 min - Compliance officer's checkpoint: a standing slot where the officer reviews the specific artifacts they need for sign-off, with the Developers present to answer. Schedule it early so they can engage and leave if needed.
- 20 min - Collaborative discussion: what changed in the market/stakeholders' needs, what to do next. New requests are captured and the PO states what each displaces.
- 5 min - PO summarizes the adapted backlog and confirms next Sprint's direction.
Handling the compliance constraint: treat sign-off as a stakeholder need to be designed into the event, not an interruption. Agree in advance which artifacts the officer needs and bring them ready. If 40 minutes is their hard limit, place their checkpoint at minute 20-30.
3. The manager says 'no one complained.' How should the Scrum Master respond, and what evidence should be gathered to make the case for change?
Read the worked answer
Reframe the success criterion: the Review succeeds when the backlog changes because of what stakeholders learned, not when no one objects. 'No complaints' often means 'no engagement,' and here the compliance officer literally walked out.
The Scrum Master should respond with curiosity, not correction: 'What would tell us the Review worked?' Then offer evidence:
- Backlog delta: how many items were added, reordered, or removed as a result of the Review? Here: zero, despite 8 stakeholders. That's the strongest single data point.
- Release delay: the compliance officer's disengagement is a release risk; track time-to-sign-off and any rework caused by late compliance input.
- Participation: who spoke, for how long. The Developers were silent; one critical stakeholder left at 40 minutes.
- Demo currency: was the demonstrated Increment from this Sprint? Here it wasn't.
- Stakeholder feedback: a two-question survey after the Review ('Did you learn something that changes what we build?' / 'Did you get what you needed?').
Present this as 'here is what the event is producing versus what it's for,' and propose a one-Sprint experiment with the redesigned format, then compare the backlog delta and sign-off time. A manager who sees a release slipping on compliance will move faster than one told the meeting is 'wrong.'