Posts

How to run sprint reviews that stakeholders actually want to attend

Most sprint reviews follow the same script: the team runs through a list of completed tickets, stakeholders nod politely, someone says "looks good," and everyone leaves. No real feedback. No course corrections. Just a ceremony that fills a calendar slot. The sprint review is supposed to be where stakeholders shape the product's direction. When it works, teams build the right thing. When it doesn't, they find out months later that nobody wanted what they shipped. Here's how to fix it.

Stop calling it a demo

The biggest misconception about sprint reviews is that they're product demos. A demo is one-directional: team shows, audience watches. A sprint review is a two-way conversation about where the product is headed. The demo is part of the review, but it's not the whole thing. A solid sprint review also covers:

• What changed in the market, with customers, or on the roadmap since last sprint
• Whether the team is on track toward the product goal, and what the data says
• What to build next based on what stakeholders just saw

When teams skip these conversations and only show completed work, stakeholders have no reason to engage. They're watching a presentation they could have gotten in an email.

Why stakeholders stop showing up

Before fixing the format, it helps to understand what drives people away:

Problem	What happens
No visible impact	Stakeholders gave feedback last time and nothing changed
Too granular	45 minutes of minor UI tweaks and bug fixes nobody asked about
Friday afternoon slot	Competing with end-of-week fatigue and early departures
Passive format	No opportunity to ask questions or try things
No context	Features shown without explaining why they matter or who they're for

The single biggest attendance killer is the first one. If stakeholders see their feedback acted on, they come back. If they don't, they won't.

A sprint review agenda that works

For a two-week sprint, plan about 90 minutes. Here's a format that keeps stakeholders engaged.

1. Set the stage (5 min)

   Quick welcome, remind everyone of the product goal and this sprint's objective. If there are new faces, brief introductions. No slides.

2. Share business context (10 min)

   The Product Owner covers what changed since last review: customer feedback, market shifts, metrics that moved. This is the context stakeholders need before they can give useful feedback on what they're about to see.

3. Show working software (40-50 min)

   Demonstrate the increment. Only show finished work that meets your Definition of Done. After each feature, pause and ask stakeholders specific questions. Don't rush from one item to the next.

4. Gather feedback and discuss next steps (20-25 min)

   Open discussion about what was shown. What should change? What's missing? What should the team focus on next? Capture everything visibly so stakeholders know their input was recorded.

5. Look ahead (5 min)

   Brief preview of what's planned for the next sprint. Ask if priorities still feel right given today's conversation. Announce the next review date.

Notice there's no "present every completed story" block. You don't need to account for every ticket. Pick the items that need stakeholder input and skip the rest.

Making the demo portion actually useful

The demo is where most reviews go wrong, so it's worth getting specific about what works. Let stakeholders drive. Instead of screen-sharing a scripted walkthrough, hand them the controls. Put the product in their hands, whether that's a staging URL, a prototype, or a live app on their device. People give better feedback when they experience something firsthand than when they watch someone else click through it. Ask specific questions, not "any feedback?" Generic questions get generic answers. Instead try:

• "Would your team use this daily or just during planning?"
• "Is anything missing before this is useful for your workflow?"
• "If you could change one thing about this, what would it be?"

Start with senior stakeholders. If a VP speaks first, others follow. If they sit silently, everyone else tends to hold back too. Direct early questions to the people whose feedback carries the most weight. Skip the trivial stuff. Don't demo bug fixes, minor styling changes, or backend refactors unless a stakeholder specifically asked for them. Showing forty minutes of incremental polish signals that nothing meaningful happened this sprint.

The feedback loop that keeps stakeholders coming back

Getting feedback during the review is only half the job. What you do with it determines whether stakeholders show up next time. Act on feedback within one sprint. This is the single most effective thing you can do. Stakeholders need to see that their input changes what gets built. It doesn't have to be everything. Even one visible change based on last review's feedback builds trust. Open the next review with what changed. Start by showing how the team responded to feedback from the previous review. "Last time, you mentioned X. Here's what we did about it." This closes the loop and proves that showing up to reviews is worth their time. Don't commit to priorities on the spot. Capture feedback, then refine and prioritize it in backlog refinement afterward. Stakeholders want to feel heard, not make scheduling decisions in real time.

Remote sprint reviews

Distributed teams face extra challenges keeping reviews interactive. A few adjustments help. Share the agenda and context ahead of time. Remote attendees who arrive cold are more likely to stay on mute the entire time. Send the sprint goal, key items to discuss, and any decisions you need input on at least a day before. Use breakout rooms for feedback. After the demo, split into small groups of 3-4 people to discuss specific features. Large video calls suppress participation. Smaller groups make it easier for people to speak up. Put the product in their hands before the meeting. Share a staging link or test build in advance so stakeholders can explore on their own. The review becomes a conversation about what they found rather than a first-look walkthrough. Use structured formats for input. Chat polls, Menti surveys, or a simple "rate this feature 1-10" in the chat give introverts and late-joiners a way to contribute without unmuting.

The science fair format for multi-team products

When multiple teams contribute to one product, sequential demos become unbearable. Nobody wants to sit through two hours of presentations from teams they don't interact with. The science fair format fixes this. After a brief all-hands kickoff from the Product Owner (10 minutes on vision and roadmap), each team sets up a "booth," either a breakout room or a physical station. Stakeholders rotate through the booths that are relevant to them. This gives stakeholders control over their time. They spend 15 minutes with the team building their features, skip the ones they don't care about, and leave feeling like their time was respected. Teams get deeper, more focused feedback instead of rushed questions at the end of a long meeting.

What the Product Owner should (and shouldn't) do

The Product Owner runs the sprint review, but how they run it makes or breaks the meeting. Do:

• Prepare an agenda and share it beforehand
• Provide business context that frames what the team built
• Facilitate discussion rather than present everything yourself
• Let developers demonstrate their own work
• Capture feedback and follow up on it

Don't:

• Present the demo as your accomplishment rather than the team's
• Accept or reject feedback on the spot. Collect it and evaluate later
• Use the review as a formal sign-off or acceptance gate
• Skip the review when the sprint goal wasn't fully met. That's when you need stakeholder input the most

The last point matters. Teams that cancel reviews after a rough sprint lose the transparency that makes scrum work. A sprint that fell short is still worth reviewing, and stakeholders respect honesty about what happened.

Measuring whether your reviews are working

You don't need a metrics dashboard, but pay attention to a few signals:

• Attendance trend. Are the same stakeholders showing up, or are you losing people?
• Feedback quality. Are you getting specific input, or just "looks good"?
• Backlog changes after reviews. Did the review change what the team builds next?
• Feedback follow-through. How much of last review's feedback made it into subsequent sprints?

If attendance is steady, feedback is specific, and the backlog adapts based on what you hear, your reviews are working. If any of those are flat, revisit the format.

Sprint review vs. retrospective

These two scrum ceremonies happen back-to-back and teams sometimes blur the line between them.

	Sprint review	Retrospective
Purpose	Inspect the product and adapt the plan	Inspect the process and adapt how the team works
Who attends	Scrum team + stakeholders	Scrum team only
Focus	What was built and what to build next	How to work better together
Output	Updated product backlog	Action items for process improvement

The review looks outward (product and stakeholders). The retrospective looks inward (team and process). Both matter, and one doesn't replace the other.