What is a Sprint Review?
Sprint Review
A sprint review is the meeting at the end of a sprint where the team shows finished work to stakeholders and the product backlog gets updated based on what they see.
A sprint review is one of the five Scrum ceremonies, held on the last day of every sprint. Its job is narrow: inspect the work the team actually finished, and use what stakeholders say about it to adjust the product backlog before the next sprint starts. It is a working session, not a status report.
The confusion around sprint reviews usually comes from two directions. People mix it up with the sprint retrospective, which happens right after it but covers a completely different topic. Or they treat it as a slide presentation summarizing progress, which defeats the point: a review only works if the team shows the thing itself, running or readable, in front of people who can react to it.
For teams new to Scrum, the sprint review is often the first ceremony to get cut when a sprint runs behind. That is backwards. A sprint that under-delivered is exactly when stakeholders most need to see what happened and why, in person, instead of finding out from a missed deadline.
Sprint Review vs Sprint Retrospective
These two ceremonies run back to back and get merged constantly, but they answer different questions for different audiences. A review asks stakeholders 'is this the right thing?' A retrospective asks the team 'are we working the right way?' Combining them means one topic always crowds out the other, usually the retrospective, since client-facing conversations tend to run long.
| Sprint Review | Sprint Retrospective | |
|---|---|---|
| Question | Is this the right product? | Are we working well as a team? |
| Audience | Team plus stakeholders and clients | Team only |
| Subject | The completed increment | The team's process |
| Output | Updated product backlog | 2-3 action items with owners |
| Timing | Right before the retrospective | Right after the review |
How Long a Sprint Review Should Run
The Scrum Guide sets a maximum of four hours for a four-week sprint, scaled down proportionally for shorter ones. In practice, most teams of five to twelve people finish well under that limit, because the point is to show what shipped, not to cover every detail.
| Sprint length | Guide maximum | Typical actual time |
|---|---|---|
| 1 week | ~1 hour | 20-30 minutes |
| 2 weeks | ~2 hours | 30-45 minutes |
| 3 weeks | ~3 hours | 45-60 minutes |
| 4 weeks | 4 hours | 60-90 minutes |
Who Actually Needs to Be There
A sprint review needs three things to be worth running: the people who did the work, the person who owns the backlog, and at least one person who can make a decision about priority. A review with no one able to redirect the backlog produces opinions that go nowhere.
For agency and studio teams, that decision-maker is the client contact or account lead. For product teams, it's the Product Owner plus whichever internal stakeholder owns the roadmap area under discussion. A review packed with observers who have no say in what happens next adds size without adding value, and tends to turn into a presentation instead of a conversation.
Running a Sprint Review for a Distributed Team
Live, synchronous reviews work well when everyone shares a few time zones. Teams spread across more than a 5-6 hour gap need a different format or someone is always attending at an inconvenient hour.
A hybrid format handles this: record a short walkthrough of each completed item (5-10 minutes total per item), post it with a written summary 24 hours before a shorter live session, and hold a written feedback window open for 48 hours after. The live session then covers only items that generated questions or disagreement, which usually cuts a 90-minute review down to 20-30 minutes.
- Record item walkthroughs and post them 24 hours before the live session
- Open a written feedback window for 48 hours, not just the meeting itself
- Live session covers only items with open questions or disagreement
- One person owns collecting written feedback into the backlog within 24 hours
Why Sprint Reviews Stop Being Useful
Most reviews degrade for one of two reasons. Either the meeting turns into problem-solving instead of demoing, with the team debugging an issue live while everyone else waits, or it turns into a one-way status broadcast where a single person clicks through screenshots describing what was built instead of showing it running.
Both failure modes have the same fix: separate discovering a problem from fixing it. Note the issue, move to the next item, and schedule the fix as a follow-up conversation. The review's only job is inspection and feedback, nothing gets solved inside the timebox.
In Melororium
See what shipped this sprint in Melororium
Common mistakes with sprint review
What teams get wrong most often, and what to do instead.
- 1
Skipping it when the sprint underdelivered
Cancelling the review because little finished feels easier than explaining a shortfall. That is exactly when stakeholders most need visibility, before a missed deadline surprises them instead of a completed conversation.
- 2
No one in the room who can decide anything
Running the review with an audience that has no authority over priority. The team collects opinions with nowhere to go, and the backlog looks the same the next morning.
- 3
Folding it into the retrospective
Merging both meetings into one because scheduling is tight. The external conversation about what got built and the internal conversation about how the team worked need separate space, or one always wins at the other's expense.
- 4
Treating the demo as a status broadcast
Describing finished work in slides instead of showing it running or readable in front of the room. A review nobody can react to produces no feedback, which defeats its entire purpose.
Frequently asked questions
Is a sprint review the same as a demo?
A demo is part of it, but a sprint review is broader. The demo shows the work; the review also includes discussion, feedback, and an update to the backlog based on what stakeholders say. A demo with no backlog follow-up is only half the ceremony.
Who runs the sprint review?
The Scrum Master typically facilitates, keeping time and structure, but the Product Owner and the delivery team present the actual work. No single person should carry the whole meeting alone.
What happens to work that isn't finished by the review?
It goes back into the product backlog for re-prioritization. Unfinished items don't automatically roll into the next sprint; the team and Product Owner decide fresh whether they're still the top priority.
Does the whole company need to attend a sprint review?
No. Invite people who did the work and people who can make a decision about what happens next. A large, low-context audience turns the meeting into a presentation instead of a working session.
How does Melororium support sprint reviews?
Project views in Melororium show progress and budget burn per project in real time, so a team can walk into a review already knowing what shipped this sprint versus what carried over, without assembling a separate status deck.
