How do you run a sprint review with a working app instead of slides?

You run it by putting a running version of the product in front of stakeholders and letting them use it, with slides reduced to a title and an agenda. The product owner prepares a short path through the app, hands the mouse to someone else, and writes feedback down as backlog items while the meeting is still going.

Why slides fail in a review

A slide about a feature is a claim. A working screen is evidence. When a team shows a screenshot of the new checkout with an arrow and a caption, the audience nods because they have no way to disagree. Then the feature ships, they use it for the first time, and the real review happens in production through support tickets.

The Scrum Guide calls the sprint review an inspection of the increment. You cannot inspect a picture of an increment. You can only inspect something that behaves. Slides also invite a speaking format: the team talks, the stakeholders listen, and the quiet ones stay quiet. With software on the screen, the format flips. People lean in, they ask can I try, and the conversation is about the product instead of about the presentation.

There is also a practical reason. Building the deck takes time that could go into the product. I have watched teams spend the afternoon before a review polishing slides for work that was already done.

Preparing a demo people can click

The aim is that a stakeholder can open a link and do the thing themselves. That means you need an environment that is not your laptop, not a developer's branch, and not production with real customer data. A stable preview or staging copy with believable data works.

Two days before the review, the product owner does a dry run. Open the app as a new user would. Log in, walk through each story finished in the sprint, and note anything that breaks, looks confusing or needs explaining. If you have to explain it, the stakeholder will need the same explanation later when you are not there. Fix it or write it down.

Then pick the path. Do not demo every ticket in the order Jira lists them. Group the finished work by what a user is trying to do: sign up, find an order, pay, get a receipt. Each group becomes one short stretch of the demo, five minutes at most. Work that has no visible surface, like a performance fix, gets one sentence, not a slot.

If part of the sprint is not finished, show it anyway, clearly marked. Half a working flow with a label saying not done yet tells the room more than a hidden story. Just do not count it as done.

What to show and in what order

• Start with the sprint goal in one sentence and whether you met it. Say it straight, including when the answer is partly.
• Show the main flow end to end first, as a user would, before any detail.
• Then show the new parts inside that flow, not as isolated screens.
• Include one edge case on purpose, like an empty list or a wrong password, so people see it was considered.
• Finish with what is not done and what you learned, in two minutes.

Keep the demo under half of the meeting. The rest is for hands on use and feedback. If your review is an hour, aim for twenty minutes of you showing and the remaining time for them driving.

Collecting feedback while they click

After the guided part, share the link in the chat and ask two or three stakeholders to do a specific task. Not explore, because exploring produces compliments. Give them a task: create a customer and send an invoice. Watch where they hesitate. Where someone hovers for five seconds without clicking is worth more than the comments they make afterward.

Assign one person from the team as the scribe, and it should not be the product owner, who is busy talking. The scribe writes every reaction in a shared document with three fields: what happened, who said it, and where in the app. Quote the person when possible. Looks confusing is useless later. I did not understand that Archive meant hiding the project, not deleting it, is something a developer can act on.

Ask better questions than do you like it. What would you do next here? What did you expect to happen when you clicked that? What is missing for you to use this on Monday? The last one is my favorite because it separates real needs from taste.

A worked example

A team builds a booking tool for a small chain of fitness studios. This sprint they finished class cancellation by members and a waiting list. Instead of slides, the product owner shares a link to a staging copy with fake members. She spends ten minutes on the path: a member logs in, cancels a class, and the next person on the waiting list is promoted.

Then she asks the studio manager, who joined as a stakeholder, to cancel a class herself. The manager clicks Cancel and the app confirms. She frowns and says, wait, what happens if it is less than two hours before the class? We charge in that case. Nobody had mentioned a late cancellation rule. The scribe writes it down as a quote, with the screen where it happened.

Another stakeholder, who runs the front desk, tries the waiting list and asks why she cannot see who is waiting. That is a second item. A third comes from a developer in the room who notices that two members promoted at once would both get the spot, and that is a real bug found in the meeting instead of at ten in the morning on a Saturday.

If you are using a tool such as StarBuild to produce the app, you also get a published preview that does not depend on anyone's machine. That kind of setup is what makes the hand over the mouse moment possible.

Turning feedback into backlog items

Within a day, sort the scribe's notes into four buckets. Bugs go straight into the backlog with steps to reproduce. Missing rules or needs, like the late cancellation fee, become new stories with a clear user and outcome. Preferences, like change the color, go in a parking list that you review at refinement, not now. And questions you cannot answer become spikes or tasks for the product owner to find out.

Write each story from the person's words. The late cancellation item might read: as a studio manager, I want cancellations under two hours before class to be flagged as late, so that I can charge the member. Add the acceptance criteria then, not in the meeting. In the meeting you only capture.

Close the loop. Send the stakeholders a short list of what came from the review and where each item landed. People give better feedback to the next review when they can see the last one changed something. If you decide not to do an item, say so and give the reason in a sentence. That builds more trust than silence.

Common ways this goes wrong

The demo breaks live. Prevent it with the dry run and a fallback: a short recording of the happy path you can play if the environment fails. The stakeholder who takes over the meeting with a redesign request: park it politely, write it down, move on. The team that only shows green paths: show an error state on purpose. And the review that turns into a status meeting, with no one touching the product. If nobody clicked anything, it was not a review.

If nobody in the room touched the product, you held a presentation, not a review.

Try it once with a small sprint. Cut the slides, share a link, and see how many surprises you collect in the first twenty minutes.