Sprint Review: How to Run One (Agenda and Examples)

A sprint review is where the team shows what they actually built. Done well, it's one of the most valuable hours in a sprint: a real conversation between the people who built the product and the people who use or fund it.

What Is a Sprint Review?

A sprint review is a formal Scrum event held at the end of every sprint. The team inspects the increment (everything done during the sprint) and collaborates with stakeholders to adapt the product backlog based on what they learn.

The Scrum Guide (Schwaber and Sutherland, 2020) defines it as a "working session" rather than a status report or a one-way demo. The distinction matters. Stakeholders aren't an audience; they're participants who help the team decide what to build next.

The sprint review is timeboxed to a maximum of four hours for a one-month sprint. Shorter sprints get proportionally shorter reviews; most two-week sprint teams keep it to one or two hours.

Key Facts

• The Scrum Guide (2020) specifies a four-hour timebox for a one-month sprint, scaled down for shorter sprints.
• The sprint review is one of five Scrum events: sprint planning, daily scrum, sprint review, sprint retrospective, and the sprint itself.
• A 2023 State of Agile report (Digital.ai) found that 71% of respondents used Scrum or a Scrum-hybrid, making sprint review one of the most widely practiced structured feedback meetings in software.

A useful framing: the sprint review answers "Did we build the right thing?" The sprint retrospective answers "Did we build it the right way?"

Sprint Review vs Sprint Retrospective

These two events happen back-to-back at the end of every sprint, so teams often blur them together. They're fundamentally different conversations.

For a full breakdown of the retrospective format and questions, see the sprint retrospective guide.

Who Attends a Sprint Review?

The Scrum Guide lists the following participants:

• Scrum Team: the developers who built the increment, the Product Owner, and the Scrum Master
• Stakeholders: anyone the Product Owner invites, such as customers, users, executives, or business sponsors
• Subject matter experts: optionally, specialists whose input is relevant to decisions about what to build next

The Product Owner typically invites the stakeholders. The Scrum Master ensures the event stays productive and within the timebox. Developers present the increment and answer questions directly. This directness is intentional. Stakeholders get unfiltered information; developers get unfiltered reactions.

Sprint Review Agenda

A well-structured sprint review moves through five parts. Here's a sample agenda for a 90-minute review (typical for a two-week sprint):

Part 1: Opening (10 minutes)

The Product Owner opens by recapping the sprint goal and listing the items planned for the sprint. Don't skip this. Stakeholders who weren't in sprint planning need context before seeing the demo.

Part 2: Increment Demo (40 minutes)

Developers demonstrate the working software. Real software, not slides. The demo should map directly to the sprint goal and show acceptance criteria being met. Each feature should be demoed in a realistic scenario, not a sanitized walkthrough.

Tip: assign each developer the features they built. They explain the context and walk through the functionality. This is more credible than having one person demo everything.

Part 3: Stakeholder Feedback (20 minutes)

This is the core of the sprint review. The Product Owner facilitates an open conversation. Questions to prompt useful feedback:

• Does this solve the problem you had in mind?
• What would make this more useful?
• What should we focus on next?
• Is anything missing or wrong?

Document everything. Stakeholder input directly shapes the next backlog update.

Part 4: Backlog Review (15 minutes)

The Product Owner walks through the updated product backlog. This is where the sprint's learning gets translated into future work. New items surface. Priorities shift. The team and stakeholders align on what matters most next.

Part 5: Close (5 minutes)

Preview the next sprint goal, confirm the next review date, and thank stakeholders. Short and clear.

How to Run an Effective Sprint Review

Step 1: Prepare the demo environment in advance

Don't wait until the morning of the review. Set up a staging environment, confirm demo accounts work, and test any live integrations the day before. A broken demo wastes everyone's time and erodes trust.

Step 2: Brief stakeholders before the meeting

Send a short pre-read: the sprint goal, what's being demoed, and any relevant context (a user workflow you're improving, a bug you fixed). Stakeholders give better feedback when they understand the starting point.

Step 3: Stick to working software

Show only what's done by the Definition of Done. If something is 80% complete, don't demo it. Showing incomplete work creates confusion and misaligned expectations. The increment is only what meets the team's standard for "done."

Step 4: Invite the right stakeholders

More isn't always better. Invite people with decision-making power or direct user insight. A focused group of five engaged people generates better feedback than a passive audience of twenty.

Step 5: Capture feedback in real time

Assign one person to document stakeholder input during the discussion. Actionable items go straight into the backlog before the session ends, or at minimum get flagged for the Product Owner to process immediately after.

Step 6: End with a clear next step

Before the room clears, state the likely focus for the next sprint. It doesn't have to be final. But leaving without any shared direction is a missed opportunity. The sprint review should feel like a chapter closing and a new one opening.

Sprint Review Best Practices

• Keep the demo realistic. Use real data or close-to-real scenarios. Artificial demos don't surface real usability problems.
• Time-box each demo segment. If a team has five items to show, allocate time per item. Without structure, demos run long and feedback gets squeezed.
• Rotate who presents. Each developer presenting their own work builds team confidence and gives stakeholders a clearer picture of the team.
• Don't mix retrospective topics in. Process issues belong in the retro. If a stakeholder raises a team-process concern during the review, note it and defer to the retro.
• Record key decisions. What did stakeholders approve? What got deprioritized? What new requests emerged? These decisions need a paper trail.

Common Mistakes

Treating the review as a one-way demo. If stakeholders are just watching and clapping, you're leaving value on the table. The sprint review is a collaborative session, not a theater performance.

Demoing features that aren't done. Showing work-in-progress as if it's complete erodes trust. If something isn't ready, say so. Skip it or show it briefly with clear caveats.

Skipping the backlog discussion. Teams that demo and dismiss miss the most important part: what changes because of what they just learned. The backlog discussion is where the sprint's output turns into the next sprint's input.

Running it without the right stakeholders. A sprint review with only internal team members is just a team sync. The value comes from external perspectives and real user feedback.

No prep. Ad hoc demos often fail or run over time. A short preparation checklist, reviewed the day before, prevents most sprint review disasters.

Frequently Asked Questions

What is a sprint review?

A sprint review is a Scrum event held at the end of every sprint where the team demonstrates the completed increment to stakeholders and gathers feedback to update the product backlog. It's a collaborative working session, not a formal presentation or status report.

How long should a sprint review be?

The Scrum Guide recommends a maximum of four hours for a one-month sprint. For two-week sprints, most teams run reviews in one to two hours. The timebox scales with sprint length: shorter sprints, shorter reviews.

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

The sprint review focuses on the product: the team shows what they built and stakeholders give feedback. The sprint retrospective focuses on the team's process: how they worked together and what to improve. Both happen at the end of the sprint, but they serve different purposes and have different participants.

Who runs the sprint review?

The Product Owner typically facilitates the sprint review, opens the session, and leads the backlog discussion. The Scrum Master ensures the event stays timeboxed and productive. Developers present the increment directly.

What happens if the sprint goal wasn't met?

The team demos what was completed. Incomplete items don't get presented as done. The gap between what was planned and what was delivered becomes an input for both the backlog update and the retrospective. Transparency here is more valuable than trying to spin the results.

---

The sprint review is one of the simplest Scrum events to run and one of the easiest to run badly. A short, well-prepared demo with the right stakeholders in the room turns every sprint into a real feedback loop. And that's what keeps teams building the right product, not just building fast.

For the other Scrum events, start with agile ceremonies and the daily standup.