--- title: "How to Run a Sprint Demo That Tells a Story" description: "How to run a sprint demo: follow one user through the problem, tie it to the sprint goal, walk through it in first person and end on outcome and next steps." canonical_url: "https://builderscamp.com/guides/other/how-to-run-a-sprint-demo" date_published: "2026-09-27" date_modified: "2026-09-27" author: "Andre Albuquerque" publisher: "Builders Camp" guide_class: "other" --- # How to Run a Sprint Demo That Tells a Story **TL;DR:** To run a sprint demo, follow one real user through the problem the sprint set out to solve: name the problem and the user, tie it to the sprint goal, walk through the new work in first person, and end on what changed and what you need. A demo that tours every feature in build order shows effort; a demo that follows one person shows value. Most sprint demos are feature tours: someone shares a screen, clicks through every new thing in the order it was built, and asks "any questions?" to silence. The fix is to run the demo as a short story about one user and one problem, in four beats. The Scrum Guide by Ken Schwaber and Jeff Sutherland says "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation." The demo is the part of that review where the team shows what changed, and it sets the quality of the conversation that follows. Plenty of teams skip the event entirely: in agile statistics compiled by [Parabol](https://www.parabol.co/resources/agile-statistics/), 53.9% of teams said they run sprint reviews synchronously and 6.5% asynchronously, with the remainder not running them at all. That figure comes from one tool vendor's audience, so treat it as a sign of how often reviews get dropped, not as an industry census. A demo that people find useful is one of the better arguments for keeping the review. ## Why do feature-tour demos lose the room? A feature tour asks stakeholders to do the hardest part of the work themselves: figure out which of the eight things on screen matters, and why. Most of them will not. They watch politely, and the questions at the end are about button colours because nobody was given anything more important to react to. The tour also hides the most useful information the team has, which is the problem the sprint set out to solve and whether it is solved. A stakeholder who sees "the new form, the upload button, the new column in the admin queue" cannot tell whether a customer's life is better. A stakeholder who watches one customer get unstuck can. ## What is the four-beat sprint demo script? A story-driven demo has four beats. The times below are for a 10-minute demo slot in a two-week sprint; scale them to your own. | Beat | What you say | Time | What to show | |---|---|---|---| | 1. Problem and user | Who was stuck, on what, before this sprint | 1 minute | A support ticket, a quote from an interview, the old screen | | 2. The goal | Which sprint or product goal this work serves | 30 seconds | The sprint goal, written on screen | | 3. First-person walkthrough | The user's path through the new work, told as that user | 4 to 5 minutes | Only the screens on that path | | 4. Outcome and next steps | What changed, how you will know it worked, what you need | 2 minutes | The metric to watch, the open decision | Two rules make the walkthrough work. First, stay on the one path: features that are not on it get a sentence at the end or a written changelog. Second, speak as the user ("I've just got home, the boiler's out, I open the app"), not as the builder ("then we added a validation step here"). First person keeps the room inside the problem. ## What does a sprint demo look like before and after? Take a hypothetical sprint on a property management app. The team shipped a new way for tenants to report maintenance problems with photos, plus changes to the queue the maintenance staff use. **Before: the feature tour.** "OK, so this sprint we built the new maintenance form. Here's the form. You can pick a category from this dropdown, which is new. There's a photo upload button here, it takes up to three photos. We added validation so you can't submit without a category. Then on the admin side, here's the queue, there's a new column for photos, and we added a filter for urgent requests. Oh, and we fixed the bug with the timestamp. Any questions?" **After: the four beats.** - **Problem and user:** "Last month a tenant reported 'boiler not working' at 9 p.m. on a Friday. The maintenance team couldn't tell whether it was a pilot light or a leak, so they sent the on-call plumber, who needed a part he didn't have. The tenant was without heat until Monday." - **The goal:** "Our sprint goal was to get maintenance staff enough information to send the right person with the right part on the first visit." - **First-person walkthrough:** "I'm the tenant. The boiler's out. I open the app, tap Report a problem, pick Heating, and it asks me for a photo of the boiler display. I take one. It asks if there's water on the floor: no. Submit. Now I'm on the maintenance team: the request lands at the top of the urgent filter, and I can see the error code on the display in the photo. I know which part to send." - **Outcome and next steps:** "We'll know this worked if the share of heating visits that need a second trip goes down over the next month. The decision we need from you: should photos be required for heating and plumbing only, or for every category?" The second version shows fewer features and says less about how they were built. It ends with a question the stakeholders can actually answer, which is what turns the rest of the review into a working session. ## Who should run the demo, and who should be in the room? The people who built the work should show it. The PM opens with the problem and the goal and closes with the outcome and the decision, and a designer or engineer does the walkthrough. That split puts the builders in front of stakeholders, answers technical questions on the spot, and keeps the PM from narrating other people's work. In the room: the Scrum Team and the stakeholders who can act on what they see, which the Scrum Guide calls key stakeholders. If a decision is on the table, the person who owns it has to be there, or the demo turns into a status update that gets repeated next week. For a decision that needs a fast answer from leadership, the structure in [how to pitch a decision to executives](https://builderscamp.com/guides/other/how-to-pitch-a-decision-to-executives) fits into beat four. ## How do you demo work that users can't see? Backend, infrastructure and data work still has a user; it is just further away. Show the effect: a page that took several seconds to load now loads before you finish the sentence, a nightly job that failed twice a week has a clean log for the sprint, an alert that woke someone up has not fired. The story is still problem, goal, walkthrough, outcome; the walkthrough is shorter and the outcome carries more weight. If nothing is visible yet, say what the work makes possible next sprint and show the smallest proof that it runs. Do not present work that fails your [Definition of Done](https://builderscamp.com/guides/glossary/definition-of-done) as finished. Stakeholders plan around what they see in a demo, and a half-built feature shown as done becomes a promised date. ## How long should a sprint demo be? Shorter than most teams make it. The Scrum Guide timeboxes the whole sprint review "to a maximum of four hours for a one-month Sprint" and adds that for shorter sprints the event is usually shorter. The demo is only the opening of that event; if it takes more than a quarter of the review, the discussion is being squeezed. A 10 to 15 minute demo for a two-week sprint is enough for one story done well, plus a few lines on smaller changes. When a sprint has two unrelated pieces of meaningful work, run two short four-beat stories rather than one long tour. ## When is a story-driven demo the wrong call? When the audience needs completeness more than meaning. A release readiness check with QA, a compliance review, or a sprint that was mostly small fixes is better served by a plain changelog read top to bottom. Wrapping twenty bug fixes in a narrative wastes everyone's time. The other risk is picking a flattering story. If the sprint missed its goal, the demo still follows a user, and the outcome beat says what did not work and what you will do about it. A demo that only ever shows successes teaches stakeholders to discount every demo. For more on running the full event around the demo, see the [sprint review](https://builderscamp.com/guides/glossary/sprint-review-ceremony) and [sprint planning](https://builderscamp.com/guides/glossary/sprint-planning-ceremony) guides; teams rethinking their rituals as a whole may also look at the [Beyond Agile](https://builderscamp.com/bootcamps/beyond-agile) bootcamp. ## How do you get better at running sprint demos? Write beat one and beat four before you open the product. If you cannot name the user, the problem and the question you need answered, the demo is not ready, however polished the build is. Then rehearse the walkthrough once, out loud, in first person. The storytelling behind the four beats is covered in [what product storytelling is](https://builderscamp.com/guides/glossary/product-storytelling-framework). The [Product Storytelling](https://builderscamp.com/bootcamps/product-storytelling) bootcamp is a 1-week programme with 2 live sessions, part of the Product Management Starter Track and the Product Leadership Track, directed by [Andre Albuquerque](https://builderscamp.com/guides/profiles/andre-albuquerque). Its public curriculum includes narrative basics (audience, tension, payoff and the "so what" that drives action) and turning stories into simple slides and crisp writing. Builders Camp runs live and self-paced bootcamps in product management and AI product building. [See the Product Storytelling bootcamp](https://builderscamp.com/bootcamps/product-storytelling?utm_source=guide&utm_medium=organic&utm_campaign=how-to-run-a-sprint-demo) for the next cohort and the self-paced version. ## Frequently asked questions ### How do you run a sprint demo? Pick one user and one problem the sprint set out to solve, say how it connects to the sprint or product goal, walk through the new work as that user in first person, then close on what changed and what you need from the room. Keep the walkthrough to the path the user actually takes, not every screen you touched. ### Is a sprint demo the same as a sprint review? No. The demo is one part of the sprint review. The Scrum Guide describes the review as a working session where the team and stakeholders inspect the outcome and decide what to do next, and says the team should avoid limiting it to a presentation. ### How long should a sprint demo be? Short enough to leave most of the review for discussion. The Scrum Guide caps the whole sprint review at four hours for a one-month sprint and says it is usually shorter for shorter sprints; for a two-week sprint, a demo of 10 to 15 minutes leaves room for the conversation. ### Who should run the sprint demo? The people who built the work, with the PM framing the problem and the goal at the start and the next steps at the end. A designer or engineer walking through their own work answers questions faster and gets credit for it. ### How do you demo backend or infrastructure work? Show the effect, not the code: a before and after of a slow page, a log of a job that used to fail, a metric that moved. If nothing is visible yet, say what the work makes possible next sprint and show the smallest proof that it runs. ### Should you demo unfinished work? Only if you label it as unfinished and ask for specific feedback on it. Work that does not meet the team's Definition of Done should never be presented as done, because stakeholders will plan around it. ### What is a feature-tour demo, and why does it fail? A feature-tour demo clicks through every new screen in the order it was built. It fails because the audience has no reason to care about screen three, and nobody can tell which change mattered. A story-driven demo picks one user journey and lets the features appear only where that user needs them. ## Sources - [Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020)](https://scrumguides.org/scrum-guide.html) - [Parabol: Agile statistics roundup](https://www.parabol.co/resources/agile-statistics/) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.