The Sprint Review That Became a Demo
A Scrum Master joins a 7-person Scrum Team at a logistics software company. The team runs two-week Sprints. The Sprint Review is scheduled for 60 minutes and is attended by the Product Owner, the team, and three stakeholders from operations. In the last four Reviews, the pattern has been identical: the developers spend 45 minutes clicking through completed features on a projector, the stakeholders ask a few polite questions, and the last 10 minutes are used to show the next Sprint's refined backlog. No stakeholder has changed a backlog item as a result of a Review in three months. The Product Owner says the Review is 'working fine' because attendance is high. Sprint Retrospectives repeatedly raise 'stakeholders don't give feedback' as the top impediment, but no action has been taken. The next Review is in five days.
1. Diagnose what is wrong with this Sprint Review using Scrum theory, and explain why high attendance is not evidence the event is effective.
Read the worked answer
The Sprint Review exists so that the Scrum Team and stakeholders can inspect the Increment and adapt the Product Backlog. Its purpose is collaboration and adaptation, not presentation. Here the event has drifted into a status demo followed by a refinement session, which is a different activity with a different purpose.
The clearest symptom is the outcome: no backlog item has changed because of a Review in three months. If inspection produces no adaptation, the event is not fulfilling its purpose regardless of attendance. High attendance only shows people are present; it says nothing about whether their input influences the Product Backlog.
The 45-minute demo consumes most of a 60-minute timebox and crowds out the discussion that would generate feedback. Showing the next Sprint's refined backlog is also misplaced: the Review inspects what was built, and forward planning belongs to refinement and Sprint Planning. The Product Owner's 'working fine' judgement rests on the wrong metric. Finally, the Retrospective is surfacing the same impediment repeatedly with no action, which suggests the team is treating a symptom (stakeholder silence) rather than the design of the event itself.
2. Propose a concrete redesign of the next Sprint Review, including how the Scrum Master should facilitate it and what the Product Owner should do differently.
Read the worked answer
Restructure around the Increment, not the slides. Keep the 60-minute timebox but invert the proportions: roughly 15 minutes for the team and stakeholders to inspect the working Increment together (hands-on where possible, with operations stakeholders trying the changed workflow rather than watching it), and 40 minutes for a structured conversation about what that means for the Product Backlog. Reserve 5 minutes to record agreed changes.
Give stakeholders a job. The Scrum Master prepares two or three focused questions in advance with the Product Owner, such as: which of these changes would reduce manual handling time, and what is missing before you could pilot it? This converts passive observers into inspectors.
Product Owner's changed behaviour. The Product Owner opens by restating the Sprint Goal and the product goal context, then actively facilitates the backlog conversation, capturing proposed changes visibly and stating which items will be reordered or added. They should not defend the work or narrate the demo.
Scrum Master's facilitation moves. Set the agenda and purpose explicitly at the start, timebox the demo portion, use a round-robin or silent-writing technique to surface feedback, and end by confirming the backlog changes aloud. Afterwards, bring the Review's outcome to the Retrospective so the team can see whether the change worked. Also agree with the Product Owner that forward-looking refinement is moved out of the Review entirely.