How to Run a Sprint Review: A Step-by-Step Guide

how to run a sprint review is a key topic in modern project management and teamwork. Most sprint reviews fail because they are designed as presentations. The team spends a day polishing a demo, the developers show a slide deck, stakeholders nod politely for an hour, and nobody says anything useful. The meeting ends, the demo is forgotten, and the Product Owner goes back to guessing what stakeholders actually wanted. That is not a sprint review — that is a show-and-tell that wastes the one opportunity the team has to steer the product with real feedback.

The sprint review is the scrum event where the team inspects what it built and collaborates with stakeholders on what to build next. It is a working session, not a presentation. This guide gives you the exact agenda, who should attend, how to demo well, what to do about unfinished work, how to capture feedback into backlog decisions, and how to run it for remote teams. Run it right and the review becomes the steering wheel of your product, not a status meeting in disguise.

Quick Answer: How Do You Run an Effective Sprint Review?

Run an effective sprint review with five steps: prepare the increment and the agenda, open with the sprint goal, demo the completed work, discuss what was accomplished and what changed in the environment, and close by collaborating on next steps and updating the Product Backlog. Keep it a working session — time-boxed to about 60 minutes for a two-week sprint, up to four hours for a month-long sprint — where stakeholders give feedback on real work, not a polished presentation.

The nuance: the review is only as valuable as the feedback it produces. Invite the right stakeholders, demo real functionality rather than slides, and make sure every piece of feedback ends up as a decision — a backlog item added, changed, reprioritized, or explicitly rejected.

What Is a Sprint Review?

The Sprint Review is the second-to-last event of the sprint, held before the Sprint Retrospective. Its purpose, per the Scrum Guide, is to inspect the outcome of the Sprint and determine future adaptations. The Scrum team presents the results of its work to key stakeholders, and progress toward the Product Goal is discussed.

During the event, the team and stakeholders review what was accomplished in the sprint and what has changed in their environment. Based on that, attendees collaborate on what to do next, and the Product Backlog may be adjusted to meet new opportunities. The Scrum Guide is explicit: the Sprint Review is a working session, and the team should avoid limiting it to a presentation.

What are the goals of a sprint review?

Atlassian summarizes them well: demonstrate completed work, collect feedback, align with the product vision, celebrate the team’s accomplishments, and identify improvements for future iterations. All five matter — and the ones teams most often skip are the last two. Without celebration the review becomes an audit; without a forward view it becomes a demo archive.

What Is the Difference Between a Sprint Review and a Sprint Retrospective?

The sprint review inspects the product: the team demonstrates the increment to stakeholders and collaborates on what to build next. The retrospective inspects the process: the team reflects on how it worked and how it will improve. The review is outward-facing — stakeholders are essential; the retrospective is internal — only the team attends.

The order is fixed: review first, then retrospective. The team cannot reflect on its process until it has inspected the product with stakeholders. If the review drifts into “how well did the team perform,” the facilitator should pull it back to the product. If the retrospective drifts into “what should we build next,” that belongs in the review and the backlog.

Who Should Attend a Sprint Review?

The Scrum team — Developers, Product Owner, and Scrum Master — plus key stakeholders: customers, business owners, subject matter experts, and anyone whose feedback shapes the product. Involving end users directly is a powerful move: a user watching a demo often surfaces usability issues that a project sponsor would never notice.

The Product Owner typically leads or anchors the session, because the review is about product direction and the PO owns the backlog. Different team members should demo their own work — this builds ownership and gives stakeholders direct access to the people who built the features.

Who should not attend?

The review is not a public stage. Large audiences of people who never interact with the product dilute the session into a broadcast. Invite the people whose feedback you need, and keep it a working group rather than an audience.

How Long Should a Sprint Review Last?

The Scrum Guide time-boxes the Sprint Review at a maximum of four hours for a one-month sprint, proportionally less for shorter sprints. For a two-week sprint, most teams run 45 to 90 minutes — Atlassian recommends 30 to 60 minutes per iteration.

The timebox forces focus: with an hour, you demo the important work, gather the important feedback, and decide the important next steps. Longer reviews rarely add proportionally more value — they add more demos of marginal work and more polite silence. Keep the agenda tight and end on time.

How to Run a Sprint Review: Step by Step

Step 1: Prepare before the meeting (before the day)

Preparation decides the review’s quality. Confirm that completed items meet the Definition of Done — only those items can be presented. Prepare the increment so the demo environment works (nothing kills a review faster than a demo that crashes). Agree on the agenda and send it with the invite: sprint goal, the items to demo, the questions you want stakeholder input on, and the timebox. Share any context stakeholders need in advance so the meeting itself is spent on substance.

Step 2: Open with the sprint goal and what happened (5 minutes)

Start by restating the sprint goal and how the sprint went against it: what was committed, what was delivered, and what was not. This sets the frame for everything that follows. Be honest about what was not finished — stakeholders need reality, not a sales pitch, to give useful feedback.

Step 3: Demo the completed work (20–30 minutes)

Walk through the actual increment, feature by feature, with the people who built it. Demo real functionality, not screenshots or slides. Let different team members present their own work. For each item, connect it to the user need it serves so stakeholders can react to value, not just visuals. Encourage questions during the demo — the review is a conversation, not a performance.

Step 4: Discuss what was accomplished and what changed (10 minutes)

Discuss the accomplished work and the state of the product and its environment: what changed in the market, what stakeholders have learned, what new opportunities or constraints appeared. This is the “inspect” half of the event — the team and stakeholders align on where the product stands right now.

Step 5: Collaborate on next steps and update the backlog (10–15 minutes)

This is the part teams skip, and the part that makes the review matter. Collect stakeholder feedback and turn it into decisions: new backlog items are added, existing ones are reprioritized, items are clarified, or requests are explicitly rejected with a reason. The Product Owner captures the decisions in the backlog during the meeting or immediately after. If feedback does not land in the backlog, the review produced opinions, not direction.

Step 6: Close and confirm next steps (5 minutes)

Summarize the decisions, confirm what was reprioritized and why, and thank the stakeholders for their time. A short check-out — “what did we decide, and who is doing what” — leaves everyone aligned. Schedule the next review’s date so stakeholders can plan around it.

How Do You Handle Unfinished Work?

If items committed to the sprint are not finished, the review still works — it just has to be honest. Do not demo half-built features as if they were done. The Scrum Guide is explicit: work that does not meet the Definition of Done cannot be presented at the review. Instead, list the unfinished items, explain why they slipped (in terms of the sprint, not excuses), and let stakeholders react to the revised plan. This is exactly the kind of transparency that builds trust — stakeholders would rather hear reality at the review than discover it at release.

Repeatedly unfinished work is a signal for the retrospective, not the review: the review records what did not ship and the retrospective digs into why.

How Do You Run a Sprint Review for a Remote or Distributed Team?

The same rules apply, plus a few remote-specific practices.

• Recorded demos for wide time zones. Teams spread across the globe record demo videos — Loom and similar tools are common — and share them for async review. Stakeholders watch on their own schedule and post feedback, and the team consolidates the feedback into backlog decisions.
• Everyone on their own video call. If the team is hybrid, apply the one-remote-treat-all-remote rule: nobody huddles around a laptop while others watch from a box on the screen.
• A shared board for the agenda and feedback. Screen-share the agenda and capture feedback live on a shared document or board so the conversation stays structured.
• Record the session for absent stakeholders. Recording the review lets people who could not attend catch up without a second meeting — but collect feedback in writing too, because comments in a live chat vanish.
• Keep the feedback loop closed. For a distributed group, the review ends when feedback is consolidated and the backlog is updated — make sure someone owns that consolidation and communicates the resulting decisions back to stakeholders.

What Tools Support Sprint Reviews?

For teams that want the review’s output to become the next sprint’s plan, Doitify’s project management platform holds the product backlog and sprints alongside project documents and meeting notes — so feedback captured at the review becomes reprioritized backlog items in the same workspace. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. The trade-off is that it is a broader platform than a single-purpose demo tool — a team that only needs to screen-share a demo can get by with a video call and a spreadsheet.

The two tools that matter most: one for the demo (the product itself), and one for capturing decisions into the backlog. A review with no backlog capture is a review with no memory.

Real Scenarios With Numbers

Scenario 1: The SaaS team that let feedback reprioritize the backlog

A seven-person SaaS team ran a sprint review where three customers joined the demo of a new reporting feature. During the demo, the customers gave feedback on a real usage pattern the team had never considered: they wanted the report’s data exported to CSV, not just viewed on screen. The Product Owner added a CSV export item to the backlog, reprioritized it above a scheduled UI polish item, and the team delivered it in the next sprint. The measurable result: the export feature was used by 40% of customers within the first month of release. A status-style review would never have surfaced that — the working session with real users did.

Scenario 2: The team that stopped demoing unfinished work

A team had a pattern of presenting half-finished features at reviews, using the demo as a progress report. Stakeholders gave feedback on features that were not functional, and the team noted rework and confusion after every review. The change: a rule that only Definition-of-Done items appear in the demo. At the next review, two committed items were unfinished and were listed honestly, with the reasons and the revised plan. The stakeholders did not punish the honesty — they engaged with the plan, and the team’s review prep time dropped from roughly four hours per sprint to one, because they stopped polishing half-done demos. The team’s release dates became more credible, and stakeholder trust rose.

Scenario 3: The distributed team using recorded demos

A ten-person team split across San Francisco, Gdańsk, and Sydney had stakeholders in three regions with a nine-hour time-zone spread. A synchronous 60-minute review was impossible for someone. They moved to recorded demos: each feature lead recorded a 5–7 minute Loom walkthrough of their work, published on a shared page, and stakeholders had 48 hours to add feedback. The product manager consolidated the feedback and updated the backlog. The result: participation actually increased — stakeholders who never joined the live calls posted written feedback — and the review decisions were documented by default. The trade-off they accepted: no live conversation, which they recovered with a monthly synchronous review for the critical demos.

Scenario 4: The review that caught a usability problem early

A team demoed a redesigned onboarding flow to a group that included two support staff members. During the demo, the support staff flagged that the new flow removed the step where users set notification preferences — a change that would have generated an estimated 30 to 40 support tickets per month, based on the ticket history for similar missing settings. The team added a preferences step back into the backlog before release. The cost of catching the issue at the review: 15 minutes of a demo. The avoided cost: dozens of tickets per month and a broken onboarding experience for new users.

Common Mistakes

• Turning it into a presentation. Slides, status reports, and polished decks kill the review. Demo real functionality and let stakeholders touch it, ask questions, and react.
• Demoing unfinished work. Only Definition-of-Done items belong in the demo. Presenting half-finished work wastes feedback and trains stakeholders to expect half-finished products.
• Skipping the backlog update. If feedback does not become decisions in the Product Backlog, the review produced opinions, not direction. Capture it during or immediately after the meeting.
• Confusing the review with the retrospective. Review = product and future, with stakeholders. Retrospective = process and past, internal. Merging them shortchanges both.
• Inviting an audience instead of stakeholders. Large groups who never use the product turn the review into a broadcast. Invite the people whose feedback shapes direction.
• Letting one person demo everything. Team members presenting their own work builds ownership and gives stakeholders direct access to the builders.
• Ignoring the environment. The review is not only about what the team built; it is also about what changed around the product — market shifts, user feedback, new constraints. Skipping that half leaves the review one-sided.
• No celebration. The review is also the moment to recognize the team’s accomplishment. A review that never celebrates becomes an audit.

Know This Before You Choose

• Decide what the review is for before the meeting: inspect the increment with stakeholders and adapt the Product Backlog. If the agenda does not serve that, cut it.
• Prepare in advance: confirm DoD compliance, get the demo environment working, and send the agenda with the invite so stakeholders come ready to react.
• Only present Definition-of-Done work, and list unfinished items honestly with the reason and the revised plan.
• Capture every piece of feedback as a decision in the backlog — added, changed, reprioritized, or rejected with a reason.
• Keep the timebox: roughly 60 minutes for a two-week sprint, up to four hours for a month-long sprint, and hold the line.
• For distributed teams, decide between live and async demos deliberately, and close the feedback loop by communicating the resulting backlog decisions back to stakeholders.

Conclusion

The sprint review is the steering wheel of your product, and it works when it is a working session, not a presentation. Prepare the increment and the agenda, demo only Definition-of-Done work with the people who built it, discuss what changed around the product, and turn every piece of feedback into a backlog decision. Keep stakeholders close — including real users — keep the timebox honest, handle unfinished work with transparency, and let the team be seen and celebrated for what it shipped. Then let the retrospective handle the process questions, and let the review handle the product ones. When you want the whole loop in one workspace — the backlog, the sprint, the demo notes, and the decisions that roll into the next sprint — Doitify’s project management platform is built for exactly that.