The sprint review is one of the most misunderstood events in Scrum. Done well, it’s the moment a team finds out whether the thing they just built actually helps anyone. Done poorly, it becomes a status meeting. Everyone nods, nobody learns anything, and the product drifts a little further from what users need.

Below are answers to the questions I get asked most often in Certified ScrumMaster training.

1. What is a sprint review?

The Scrum Guide describes the sprint review as an event where the Scrum Team and stakeholders inspect what the sprint produced and decide what to do next. The team shares its results, the group discusses progress toward the product goal, and the product backlog can be adjusted based on what comes out of the conversation. (Read the full Scrum Guide description here.)

Two details matter more than people realize: First, it’s a working session, not a presentation. If your stakeholders are sitting quietly while someone clicks through screens, you’re not getting the value of the event. Second, it’s timeboxed to four hours for a one-month sprint, and proportionally shorter for shorter sprints.

2. Sprint review vs. sprint retrospective: what’s the difference?

This is the question I get most, so it’s worth being precise.

	Sprint Review	Sprint Retrospective
Focus	The product	The team and how it works
Question it answers	Are we building the right thing?	How can we work better together?
Who attends	Scrum Team plus stakeholders, users, customers	Scrum Team only
When	Second-to-last event of the sprint	Final event of the sprint
Output	Feedback and possible backlog changes	Improvements the team commits to

The short version: the review inspects what you built. The retrospective inspects how you built it. Teams that collapse the two into a single meeting usually end up shortchanging the retrospective, because product conversations are louder and stakeholders are in the room.

3. Who attends a sprint review?

The Scrum Team (Product Owner, Scrum Master, and Developers) host. From there, invite anyone whose feedback would improve the product: end users, customers, subject matter experts, stakeholders, leadership, and people from other teams who depend on your work.

A useful filter when you’re deciding whom to invite: whose reaction would change what we do next? Those are your people.

4. Do all Developers need to attend, or can some keep working?

I recommend all Developers attend. When the whole team hears the same feedback directly, you skip the game of telephone entirely. Developers can answer questions in real time, offer context a summary would lose, and see firsthand how people react to what they built. This live feedback tends to change how they build the next thing.

There’s also a practical argument: the previous sprint is over and the next hasn’t started, so there’s no active sprint backlog to pull from. There isn’t other work being protected.

5. What is the purpose of the sprint review?

To inspect the outcome of the sprint and determine future adaptations. In simpler terms: to find out from real users, customers, and stakeholders whether what you built actually meets their needs, while there’s still time to do something about it.

Here’s what it is not. I’ve watched plenty of sprint reviews turn into a checklist read-aloud:

“Welcome, everyone. Our goal was 80 points. User story on: finished, 13 points. User story two: not finished. User story three: finished, 8 points…”

That’s just a status readout. Nobody in the room learned anything about the product, and the stakeholders you invited just watched a team recite arithmetic at them. Inspect and adapt the product, not the points.

6. When does the sprint review happen?

At the end of the sprint, but before the retrospective. This order is important.

Picture it flip-flopped. The sprint went beautifully: goals met, everything done, Product Owner happy. The team runs its retrospective first, agrees it was a great sprint, and celebrates. Then they walk into the sprint review and learn that users find the feature confusing and a little buggy.

Now they need a second retrospective to process what they just heard. Running the review first means the feedback is available as input while the team is reflecting, which is the whole point.

7. Should the sprint review be the first time the Product Owner sees the increment?

No, and if it is, you have bigger problems. Imagine the team presenting in front of users, customers, and leadership when the Product Owner says, “What is that? That’s not what we agreed to.” A Developer replies, “It’s exactly what the story says.” The Product Owner answers, “I wrote that story. It wasn’t supposed to look like this.”

That exchange needed to happen, but ideally not with an audience. It erodes confidence in the team and derails the feedback you gathered everyone to give.

Two habits prevent it. The Product Owner should be reviewing completed work throughout the sprint. And the Scrum Team should hold a short sync before the review so the session runs cleanly for the people attending.

8. Who facilitates the sprint review?

The Scrum Guide doesn’t assign this. It can be the Product Owner, the Scrum Master, a Developer, or someone outside the team entirely.My recommendation depends on team maturity. Early on, let the Scrum Master run it. Facilitation is their strength, and a well-run session sets expectations for everyone attending.

As the team matures, I like a handoff. The Product Owner opens by framing the sprint goal and why it mattered. Developers take over to show what they built. Ideally, attendees get hands on it themselves rather than watching a demo.

That structure frees the Product Owner to do the most valuable job in the room: listening. Taking notes, answering questions, catching the offhand comment that changes the roadmap. That’s hard to do while also facilitating.

9. How long should a sprint review be for a two-week sprint?

The Scrum Guide caps it at four hours for a one-month sprint. Scale proportionally: a two-week sprint gets two hours or less.

Treat that as a ceiling, not a target. A focused 45-minute review where stakeholders actually engage is better than a two-hour session that runs out of energy halfway through.

10. What are the most common sprint review anti-patterns?

Here’s a quick diagnostic list. If several of these sound familiar, the event is worth redesigning:

• The demo-only review. One person drives, everyone else watches without interaction or feedback.
• The status report. Story-by-story breakdowns instead of a product conversation.
• The rehearsed performance. So polished that nothing unexpected can surface (which means nothing useful will).
• No real users in the room. You need feedback from people who actually use the product.
• Feedback that goes nowhere. If nothing changes, your stakeholders will probably stop showing up.
• Skipping it when the sprint went badly. These are the reviews you need most.

Making the sprint review worth everyone’s time

The sprint review works when the right people are in the room, the team is genuinely curious about the answer, and the feedback visibly shapes what happens next. It’s that simple.

Want to facilitate sprint reviews (and every other Scrum event) with more confidence? Join us for Certified ScrumMaster (CSM) training and practice these conversations before you run them live.