NarrateHow to structure a sprint review presentation (with templates for 15 and 30 minutes)
A practical guide to sprint review presentations - what to include, what to cut, and two ready-to-use slide templates for 15 and 30-minute reviews.
Most sprint review presentations have the same problem: they try to cover everything, run long, and leave the actual discussion squeezed into the last two minutes.
A better sprint review does not come from a better template. It comes from understanding what the presentation is actually supposed to do.
What is a sprint review presentation actually for?
The sprint review is not a demo showcase or a status report. The Scrum Guide describes it as a working session: the goal is to inspect what was built, gather feedback, and decide what happens next.
The deck's only job is to get the room aligned fast enough that there is time for an actual conversation. A good sprint review presentation does four things: orients the room, makes the increment easy to inspect, gives just enough evidence to judge delivery health, and funnels everyone toward a decision.
If it does all four, the review works.
What should every sprint review include?
The structure stays the same regardless of how long the review is. The sequence matters because each step sets up the next.
1. Context - sprint dates, team, product area. One slide. Thirty seconds.
2. Product goal - the overarching goal the team is working toward. Anchors everything that follows.
3. Sprint goal - what this sprint specifically set out to accomplish. Everything you show should trace back to this.
4. Completed outcomes - what is done, phrased as user or business change, not ticket IDs. "Onboarding step reduced from 6 fields to 3" lands better than "JIRA-142 completed."
5. Live demo or proof - show the thing. For user-facing work, a live demo is almost always better than screenshots. For backend or infrastructure work, a workflow trace, error-rate change, or before-and-after comparison does the same job.
6. Delivery evidence - one metrics slide, maximum. Sprint goal achievement, carry-over if relevant, and one chart only if it would change how someone interprets the work.
7. Feedback and decisions - what changed in backlog ordering, what needs to be decided, what follow-ups are assigned. Most reviews cut this short. Do not.
How long should your sprint review be?
The right length depends on the size of the increment, not habit. Most teams default to 60 minutes because that is what is in the calendar. Most reviews would be better at 30.
| Review length | Slide count | Demo time | Discussion time | Best for |
|---|---|---|---|---|
| 15 minutes | 5-6 slides | ~50% | ~25-35% | Small team, one major thread, familiar audience |
| 30 minutes | 8-10 slides | ~45% | ~35-40% | Typical single-team sprint, mixed audience |
| 60 minutes | 12-15 slides | ~40% | ~40% | Multiple demo themes, broader stakeholder group |
The rule for all three: compress the deck, not the conversation. If something has to give, cut slides, not discussion time.
What is the right slide structure for a 15-minute sprint review?
| Slide | What to show | Time |
|---|---|---|
| Sprint context | Sprint dates, team, product area, one-sentence sprint theme | 1 min |
| Product goal + sprint goal | Why this sprint mattered, what success looked like | 1 min |
| Completed outcomes | 2-4 outcomes phrased as user or business change | 2 min |
| Live demo | One focused walkthrough from problem to solved state, no side quests | 7 min |
| One metrics slide | Sprint goal achievement, carry-over, one chart only if it changes interpretation | 2 min |
| Feedback and next priorities | Open questions, immediate reactions, any backlog changes | 2 min |
In a 15-minute review, resist the urge to demo everything that shipped. Show the work most likely to change understanding or priorities. Leave the rest in the appendix or skip it.
Stakeholders disengage fast when a review becomes a tick-through of completed tickets, and you lose the discussion before you get to anything worth discussing.
What is the right slide structure for a 30-minute sprint review?
The 30-minute format is the most useful default. It has enough room for two demo threads and real discussion without bloating into a presentation.
| Slide | What to show | Time |
|---|---|---|
| Title and context | Sprint dates, team, product area, reminder of the review's purpose | 2 min |
| Product goal + sprint goal | Connection between this sprint and broader product direction | 2 min |
| Completed outcomes | 3-6 outcomes grouped by theme | 3 min |
| Demo thread one | First user flow or business process change | 6 min |
| Demo thread two | Second flow, or technical evidence for non-UI work | 6 min |
| Delivery evidence | One compact metrics view: goal completion, one flow metric | 4 min |
| Implications | Risks, dependencies, release or market context - anything that requires stakeholder attention | 5 min |
| Feedback and decisions | What changed in backlog ordering, what must be decided, who owns what | 2 min |
Most teams cut the implications slide because raising risks and constraints in front of stakeholders feels uncomfortable. Cut it anyway and the feedback you get back will be blind to the actual situation.
One slide, five minutes: release timing, budget, anything that changes how priorities should be read.
What are the most common sprint review mistakes?
Demoing everything completed. The review becomes a status parade. Stakeholders disengage. Curate the demo around what most needs feedback, not what was most recently shipped.
Too many metrics. Three charts on one slide is not evidence. It is noise. Show only the metrics that would change a decision or an interpretation. If a chart would not change anything, it belongs in the appendix, not the main deck.
No business context. A review that covers completed work but not release timing, budget shifts, or market changes leaves stakeholders guessing at priorities they cannot actually see. The feedback you get back reflects that.
Treating it as a one-way presentation. The most common failure. Teams spend 55 of 60 minutes presenting, then wonder why the discussion is shallow. The deck should set up the conversation, not replace it. If your slides are doing all the talking, something is wrong.
Rebuilding the deck every sprint. The structure does not change sprint to sprint. Only the content does. If you are starting from scratch each time, that time belongs on the actual work.
Building your sprint review in Narrate
Narrate's sprint review template follows this structure. Swap in the content each sprint: outcomes, screenshots, metrics, decisions. The layout handles itself.
Stakeholders get a link, not a file. No download, no account, no "what version is this?" If you need roadmap context, the Gantt timeline block is already there. Metrics go into a data table: clean, readable, no chart-building required.
FAQ
Frequently asked questions
- How many slides should a sprint review have?
- For a 15-minute review, 5-6 slides. For a 30-minute review, 8-10 slides. For a 60-minute review, 12-15. The number matters less than whether each slide is doing a specific job in the sequence: orient, outcomes, proof, evidence, decisions.
- What is the difference between a sprint review and a sprint retrospective?
- The sprint review is about the product - what was built, whether it advances the product goal, and what stakeholders think. The retrospective is about the team's process - how the sprint went and what to improve. They are separate events and should stay that way.
- Should you demo everything that was completed in the sprint?
- No. Demo the work that is most likely to generate useful feedback or change how stakeholders understand priorities. Everything else can go in an appendix or be skipped. Reviews that show every completed item become long and disengaging.
- What metrics should you show in a sprint review?
- Only the metrics that would change a decision. Sprint goal completion, carry-over rate, and one flow metric such as velocity trend or cycle time is usually enough. If showing a chart would not change how anyone in the room interprets the work or thinks about priorities, leave it out.
Try Narrate free
Stop rebuilding decks. Start with a structure that already works.
Build the next update as a web-native presentation: structured sections, shareable links, presenter mode, and clean PDF export.