The Sprint Review That Became a Status Meeting
A Scrum Team at a logistics company runs two-week Sprints. The Product Owner has started inviting 15 stakeholders to the Sprint Review and presenting a slide deck of completed Jira tickets himself, while the Developers sit silently at the back. Stakeholders use the last 20 minutes to request new features directly to the Product Owner, who promises several to the loudest manager. The Developers leave the review without understanding what feedback was gathered, and the Product Owner's backlog ordering diverges from what the team built. The Scrum Master notices that the Sprint Review regularly overruns to 90 minutes and that no one discusses the increment itself.
1. What is the primary purpose of the Sprint Review, and how is this team failing to serve it?
Read the worked answer
The Sprint Review exists to inspect the outcome of the Sprint and determine future adaptations, and to collaborate with stakeholders on what to do next. It is a working session, not a status report.
This team fails in three ways:
- The Product Owner narrates tickets instead of the team demonstrating the working increment, so stakeholders cannot inspect the actual product.
- Developers are silent, so the people with the deepest product knowledge are excluded from the conversation.
- Stakeholder input is captured as verbal promises rather than being weighed and reflected in the Product Backlog, so inspection produces no transparent adaptation.
The Scrum Master's job here is to coach the team and stakeholders on the event's purpose and to help the Product Owner shift the format toward demonstrating the increment and discussing the Product Backlog.
2. Should the Scrum Master simply enforce the timebox and cut the meeting at 60 minutes? Explain the reasoning.
Read the worked answer
Enforcing the timebox alone treats a symptom. The overrun is caused by the format - a slide presentation plus open-floor feature requests - not by poor discipline.
A sound approach: first coach the Product Owner and team on the purpose of the Review and the value of a working increment demo; help restructure the agenda (context, demo of the increment, discussion of the Product Backlog and next steps). Then keep the timebox as a guardrail. Simply stopping a productive conversation at the buzzer, or conversely letting it run indefinitely, both miss the point. The Scrum Master serves the team by teaching the why before enforcing the what.
3. What should happen to the feature requests shouted by stakeholders during the Review?
Read the worked answer
They are inputs to the Product Backlog, not commitments made in the room. The Product Owner owns ordering and is accountable for maximizing value; any stakeholder can propose, but only the Product Owner decides what enters the backlog and in what order.
A good practice is to capture the requests transparently (e.g., a visible parking lot) and have the Product Owner reflect them in the Product Backlog after the Review, weighing them against everything else. Promising features on the spot undermines empiricism because it commits to work that has not been inspected or ordered against other priorities.