Sprint review: purpose, attendees, and how to run one

The sprint review is the ceremony where the team shows working product to stakeholders and gathers the feedback that reshapes what it builds next. It happens at the end of the sprint, it’s timeboxed to about two hours for a two-week sprint, and its output is a changed product backlog. The thing to hold onto: it’s a working session, not a performance. The value isn’t the demo — it’s the decisions the demo triggers.

What the sprint review is for

The review exists to answer one question with the people who care about the outcome: given what we just built, what should we build next?

The team presents the increment — the work that’s genuinely done, against the definition of done, not the work that’s nearly there — and the stakeholders in the room respond. They ask questions, they push back, they notice the thing nobody thought to mention in planning. That reaction is the product of the meeting. It flows straight into the product backlog, which the product owner adjusts on the spot or shortly after.

Sprint review vs demo

People use “sprint review” and “the demo” as if they’re the same meeting. They’re not — the demo is one part of the review.

Showing the working software matters: it forces honesty (you can’t demo a nearly-finished feature) and it gives everyone the same concrete thing to react to. But if the demo is all that happens — the team presents, stakeholders clap, everyone leaves — you’ve run a one-way broadcast. The review is the two-way conversation the demo is supposed to start. The demo is the setup; the feedback and the re-prioritisation are the point.

Who attends, and why it faces outward

The sprint review is the one ceremony built to face outward. Attendees are the whole Scrum Team plus the stakeholders the product owner invites — customers, users, sponsors, support, anyone whose reaction should influence the product.

That guest list is a decision, not a formality. Invite people who can give feedback worth acting on, and curate ruthlessly: a room full of spectators produces polite noise; a room with the right three customers produces a re-ordered backlog. This outward stance is exactly what separates the review from the sprint retrospective, which is team-only and private for a reason.

How to run one that’s worth the hour

The format is deliberately light. Keep it a working session, not a stage show.

• Open with the sprint goal. Remind the room what this sprint set out to achieve, so the increment is judged against intent, not vibes.
• Show working product, not slides. Demo the real thing against the definition of done. Skip the near-done — it invites debate about work that isn’t finished.
• Make space for reaction. The team should be listening more than presenting. Questions, objections, and “could it also…” are the material you came for.
• Close by updating the backlog. Fold the feedback into priorities while it’s fresh. That’s the artifact the meeting produces.

Preparation is mostly restraint: pick what to show, make sure it actually runs, and resist the urge to build a deck. Ten minutes of a feature working beats forty minutes of screenshots of it.

Sprint review vs sprint retrospective

The two closing ceremonies get confused constantly, so hold the line: the review inspects the product with stakeholders; the retrospective inspects the team’s process, privately. The review faces outward and runs first; the retrospective faces inward and runs second, so the team can carry fresh product feedback into its own reflection.

They don’t combine well — nobody raises “our testing is rushed” in front of the customer, so merging them quietly kills the honest half. We keep the full comparison, including who attends each and why to keep them apart, in sprint review vs sprint retrospective. For where both sit among the rest of the meetings, see the four Scrum ceremonies and this guide’s other ceremonies.

Frequently asked questions

What is the purpose of a sprint review?

To inspect the product increment with stakeholders and adapt what happens next. The team shows what it actually finished, stakeholders react, and that reaction feeds back into the product backlog. The point isn’t the applause — it’s the course correction. A review that changes nothing about the plan was a status meeting in disguise.

Who attends a sprint review?

The whole Scrum Team plus the stakeholders the product owner invites — customers, users, sponsors, anyone whose feedback should shape the product. It’s the one ceremony that deliberately faces outward. The product owner curates the guest list so the feedback in the room is worth acting on.

How long should a sprint review be?

Timebox it to about two hours per week of sprint — up to two hours for a two-week sprint, up to four for a month-long one. If it’s overrunning, you’re probably presenting slides instead of showing working product, or reviewing work that wasn’t actually done.

What is the difference between a sprint review and a demo?

A demo is one activity inside the review — showing the working software. The sprint review is the wider conversation the demo starts: stakeholders reacting, priorities shifting, the backlog changing. Treat the review as only a demo and you get a one-way presentation that produces nods and no decisions.

What is the difference between a sprint review and a retrospective?

The sprint review inspects the product with stakeholders — what to build next. The retrospective inspects the team’s own process, privately — how to work better next sprint. The review faces outward and comes first; the retrospective faces inward and comes second. You need both, and they don’t combine well.