How to Run a Sprint Review

What the sprint review is actually for

The sprint review is not a performance review of the team. It is not a client presentation polished to impress. It is not a sign-off gate before the next sprint can start. It is an inspect-and-adapt conversation: the team shows what was built, stakeholders respond with honest feedback, and the backlog is updated to reflect what was learned. That is the whole point.

The retrospective happens separately and looks inward at the team's process. The review looks outward at the product. Mixing the two - or skipping one because you ran out of time in the other - means you lose either the team feedback loop or the stakeholder feedback loop. Both matter. Keep them separate.

What to prepare before the session

A poorly prepared sprint review is painful for everyone in the room. Broken demos, engineers scrambling to remember what they built, stakeholders checking their phones. None of that is inevitable - it is all a preparation problem. Twenty minutes of prep before the session is worth an hour of patching during it.

• Know the sprint outcomeBefore anyone walks into the room, confirm exactly which stories were completed, which were not, and whether the sprint goal was met. Do not discover this live. The team should agree on this before the review starts so there are no surprises when a stakeholder asks directly.
• Prepare the demo environmentSet up and test the demo environment the day before. Use a staging environment, not production. If the feature requires data to demonstrate, seed it. Nothing derails a review faster than a broken environment or a blank screen where the new feature should be. A dry run is worth fifteen minutes.
• Decide who demonstrates whatThe engineer who built the feature is often the best person to demo it - they know the edge cases and can field questions with authority. Brief them on what to show, how long they have, and what questions to expect. Do not leave this to chance the day of the review.
• Share the agenda in advanceSend stakeholders an agenda the day before. List the sprint goal, the features being demoed, and how much time is set aside for feedback. This lets people show up with specific questions rather than vague impressions. It also signals that this is a working session, not a passive presentation.

A structure that works

A sprint review does not need a complex agenda. Four beats in order, each with a clear purpose, keeps the session focused regardless of what you are demoing or who is in the room.

• Open (5 min)State the sprint goal and say whether it was met. Briefly list what was completed and what was not. Do not apologise for incomplete work at this stage - just state it factually. Stakeholders appreciate honesty and clarity over polish.
• Demo (15-25 min)Show working software. Each team member demonstrates their completed feature in the actual product, not in slides. Keep each demo to five minutes or less. Focus on how the feature works from a user perspective, not on the technical implementation. Hold questions until after each demo.
• Discuss (15-20 min)Open the floor for feedback. Ask specific questions rather than "any thoughts?" - you will get far better responses. What does this change for your team? Is this what you expected to see? What would make this more useful? Someone should be taking notes in real time.
• Align (5 min)Close by summarising what you heard and what it means for the backlog. Are any stories being revised? Is anything being added based on the feedback? What is the priority going into the next sprint? This final beat is what separates a review that produces change from one that produces a polite round of applause.

Getting real feedback from stakeholders

The most common sprint review failure is not a broken demo or an incomplete sprint. It is passive stakeholders who nod along and leave without saying anything useful. This is almost always a facilitation problem. "Any feedback?" after a demo invites silence. Specific, directed questions invite honest responses.

Before the discussion opens, tell stakeholders what kind of input you are looking for. "We want to know if this solves the problem you originally described, and whether the flow makes sense to someone unfamiliar with it" is far more useful than an open invitation. It gives people permission to be critical and signals that you want honest input, not approval.

• Ask specific questionsInstead of "what do you think?", try: "Does this match what you were expecting?" or "Is there anything here that would stop this being useful for your team?" or "What is missing from this that you would still need?" Specific questions surface specific answers.
• Invite the scepticIf you know there is a stakeholder who has reservations about the approach, give them space to voice it in the room. "I know you had concerns about the earlier design - does this address them?" is uncomfortable but produces far more useful feedback than hoping someone raises it after the meeting.
• Name disagreements openlyIf two stakeholders disagree about whether something is right, write it down and name it. "We have different views on this, so we need to make a decision before the next sprint" is a healthy outcome. Letting disagreements stay implicit means they surface later, at a worse time, with more work already done.
• Avoid defending the workThe instinct to explain why something was built a certain way, or to justify a design decision when challenged, kills feedback conversations. When a stakeholder says something does not work for them, the right response is to understand why - not to explain the technical reasoning. Save the context for later if it matters.

When the sprint did not go to plan

Every team will have sprints where work is incomplete, the demo environment fails, or a feature is further from done than anyone expected. How a manager handles this in the review shapes how stakeholders interpret it. There is a significant difference between "we did not finish this" said defensively and "we did not finish this, and here is what we learned and what it means for next sprint."

• Be factual, not apologeticState what was not completed and why, briefly and without drama. "The payment integration took longer than estimated because of an unexpected API change" gives stakeholders something to work with. A long apology, or silence about what was missed, leaves people filling in the gaps with their own assumptions - which are usually worse than the truth.
• Only demo what is doneNever demo partially completed features as if they are finished. If it is not shippable, do not show it. Demoing half-built work to manage expectations almost always backfires - stakeholders focus on what is missing and the team looks disorganised. Describe what is coming instead, and show it when it is genuinely ready.
• Explain the impact on prioritiesIf incomplete work changes the plan for next sprint, say so explicitly. "We are carrying this forward, which means we need to deprioritise X" is the kind of decision stakeholders need to be part of. Carrying work silently without flagging the trade-offs creates surprises later that are much harder to manage.
• Do not over-explain in the roomA brief, honest account of what happened is enough. The sprint review is not the place for a detailed post-mortem on what went wrong. The retrospective and, if needed, a separate post-mortem are the right venues for that. In the review, acknowledge, explain briefly, and move forward.