The Sprint Review Is Not a Demo
The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog.
The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog. The output is not a sign-off — it is updated understanding of what should be built next, in light of what was just built. If the product owner leaves a sprint review without having adjusted the backlog based on something learned in the meeting, the meeting failed its purpose.
This distinction has structural implications. A demo can be rehearsed and controlled. A sprint review cannot, if it is functioning correctly. Stakeholders need to be able to interact with the increment, not watch it be operated. Questions that expose gaps in the implementation should be welcomed, not managed. The product owner needs to be empowered to say, in the room, that the priority order is changing based on what they just saw.
The stakeholder composition matters more than most teams acknowledge. A sprint review attended only by the immediate product team is an internal sync with extra steps. The people who attend should be the people whose feedback would change what the team builds — business owners, end users when possible, downstream teams with dependencies. If those people are not in the room, the team is reviewing with itself.
The sprint review is the point in the scrum cycle where the empirical loop closes at the product level. The retrospective closes it at the process level. Both require genuine engagement with what the data — the increment, the user response, the stakeholder reaction — is actually showing. A demo produces no data. A review does.