The Sprint Review That Became a Demo
A Scrum Master joins a team six months into using Scrum. The team ships a B2B billing product. The Sprint Review has drifted into a 90-minute slide presentation that the Product Owner delivers alone to about 12 stakeholders, most of whom are sales and support staff. The team sits silently at the back. Stakeholders ask few questions and leave. The Product Owner then spends two days writing a requirements document for the next Sprint, and the team complains that priorities change mid-Sprint. The company's quarterly revenue target is tied to a feature the sales team keeps requesting, but nobody has seen working software for it in three Sprints. The Scrum Master has one retrospective, one Sprint Review, and one Sprint Planning before the next quarterly business review with the executive team.
1. What is the most likely root cause of the review's failure, and what should the Scrum Master change first?
Read the worked answer
The Review has lost its purpose: it is meant to be a working session where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog together. A one-way slide deck delivered by the PO removes both inspection and collaboration, so stakeholders get no evidence and the team gets no feedback.
First change: replace the slide presentation with a live inspection of the working Increment against the Sprint Goal and the Product Goal, and structure the remaining time as a facilitated conversation about what to do next. The PO still owns the Product Backlog, but the review is a team event, not a PO performance.
The Scrum Master should not 'fix' the symptom (better slides). The symptom - silent team, absent questions, churn after the review - is downstream of an event that produces no shared information.
2. The PO argues the slide deck is necessary because 'stakeholders are busy and the software is half-built.' How should the Scrum Master respond, and what does this reveal about the Sprint Goal?
Read the worked answer
The 'half-built' objection is the strongest signal that something is wrong upstream. If three Sprints have produced nothing stakeholders can inspect, the team may be building components rather than a usable, valuable Increment, or the Sprint Goals may not be coherent slices of value. The Scrum Master should ask the PO and team to look at the last three Sprint Goals and ask: did each one produce something a stakeholder could evaluate?
On the 'busy stakeholders' point: shortening or restructuring the Review is legitimate (the event is timeboxed and can be shaped), but removing inspection is not. A 45-minute review with a live walkthrough and a focused question set can respect stakeholders' time better than 90 minutes of slides.
This is a coaching moment, not a compliance lecture: help the PO see that the deck exists because the Increment doesn't yet answer the stakeholders' real question.
3. The sales-driven feature keeps getting requested but never appears. What should the Scrum Master facilitate before the quarterly business review?
Read the worked answer
The recurring request with no visible progress usually means the Product Backlog is not transparent about why it isn't being done, or the team is being asked to absorb it mid-Sprint without re-planning. The Scrum Master should facilitate a conversation (not a decision) between the PO, the team, and a sales representative to surface:
- What evidence would tell us the feature is worth more than what we're doing now?
- Where does it sit in the Product Backlog, and what would we stop doing to start it?
- Why do priorities appear to change mid-Sprint - is the PO being overruled, or is the team not protecting the Sprint Goal?
The Scrum Master does not decide priority. The output should be a clearer, ordered Product Backlog and an explicit agreement about how mid-Sprint changes are handled, so the quarterly review discusses trade-offs rather than blame.