Sprint Review: Purpose, Agenda & Timebox [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 23, 2026
11 min read
The sprint review is the moment a sprint's work meets the real world — where the people who care about the product see what got built and say what they think. Run as a box-ticking demo, it wastes everyone's afternoon; run as the working session it's meant to be, it quietly steers the whole product. The difference comes down to one idea most teams miss: the review exists to adapt the plan, not just to show the work. This guide explains the sprint review in full — its purpose, who attends, the timebox, a working agenda, how it differs from the retrospective, and how it appears on the PMP and CAPM exams.
What is a sprint review?
A sprint review is the Scrum event held near the end of each sprint where the Scrum team and its stakeholders inspect what the sprint produced — the increment — and collaborate on what to do next. It is the second-to-last event of the sprint, coming just before the retrospective, and its job is to turn finished work into informed decisions about the product's direction.
Rather than a formal presentation, it is a working session: the team shows the increment, stakeholders react, and together they decide what the newest information means for the product backlog. The tangible output is not applause for a demo but an adapted backlog — reprioritized, added to, or trimmed in light of what everyone just learned. If a sprint is a bet on delivering something valuable, the sprint review is where the team and its stakeholders check the result and place the next bet together.
The purpose of a sprint review
The purpose of a sprint review is to inspect the increment, gather feedback from stakeholders, and adapt the product backlog so the next sprint reflects the latest reality. It is Scrum's built-in checkpoint for answering the question "are we building the right thing?" — and adjusting course while adjusting is still cheap.
That purpose plays out in three moves. First, the team inspects the increment with the people who have a stake in it, so feedback comes from those who will actually use or sell the product, not just from inside the team. Second, it surfaces change: shifts in the market, budget, timeline, or user needs get raised while there is still a whole product backlog to reshuffle in response. Third, it feeds the backlog: the product owner and stakeholders collaborate on priorities, and the backlog leaves the room reflecting decisions rather than assumptions. A sprint review that ends without a single change to the backlog usually means the feedback loop never actually closed.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
A sprint review is more than a demo
The single most common misunderstanding is treating the sprint review as a demo — the team presents finished features, stakeholders nod, everyone leaves. The demo is real and useful, but it is the opening of the review, not the whole of it. Showing the work is how the conversation starts; the value is in the conversation.
The distinction matters because a pure demo is one-directional: the team broadcasts, the audience receives, and nothing changes. A genuine review is a two-way working session: stakeholders question, suggest, and challenge; the team explains trade-offs; and the group jointly decides what to build next. When teams collapse the review into "demo day," they keep the ceremony but lose the point, which is why so much agile writing insists the sprint review is more than just a demo. If you walk out having only shown work — with no feedback captured and no backlog changed — the review didn't happen; a presentation did.
Who attends a sprint review?
A sprint review brings together the whole Scrum team and the key stakeholders who care about the product. Unlike the internal daily standup or retrospective, this is the deliberately outward-facing event — the one time each sprint the team and its audience sit down together.
- The Scrum team. The developers present the increment and answer questions, the product owner frames progress toward the product goal and leads the backlog discussion, and the Scrum Master ensures the event happens and stays productive.
- Key stakeholders. Customers, users, sponsors, and business representatives invited by the product owner — the people whose feedback should actually shape the product. Their presence is what separates a review from an internal check-in.
The product owner curates the guest list: enough of the right stakeholders to get meaningful feedback, without turning the session into an unwieldy crowd. The people who attend the daily standup are the team; the people who attend the review are the team plus the voices the product is being built for.
How long is a sprint review?
A sprint review is timeboxed to a maximum of four hours for a one-month sprint, and proportionally less for shorter sprints — a useful rule of thumb is about one hour per week of sprint length. A two-week sprint, therefore, gets a review of roughly two hours.
As with every Scrum timebox, this is a ceiling rather than a target: a focused team with a genuinely "done" increment often needs far less. The length exists to keep the session purposeful — long enough for real feedback and a proper backlog conversation, short enough that it stays a working meeting rather than a marathon. Most teams running two-week sprints find an hour or two is plenty when the increment is ready and the right people are in the room.
What happens in a sprint review? The agenda
A good sprint review follows a simple arc: show the work, gather feedback, and decide what's next. The agenda below covers what an effective review works through, in order.
- Set the context. The product owner recaps the sprint goal and where the product stands relative to the longer-term product goal, so feedback lands against the right backdrop.
- Show the "done" increment. The team demonstrates the completed work — and only work that genuinely meets the definition of done. Half-finished features don't belong in a review; showing them invites feedback on an illusion.
- Discuss what was and wasn't completed. The team is honest about what the sprint plan delivered and what slipped, and why, so stakeholders understand the real state of progress.
- Gather feedback and surface change. Stakeholders react to the increment and raise anything new (market shifts, changed priorities, budget or timeline moves) that should influence what comes next.
- Adapt the product backlog. Together, the group reprioritizes, adds, or removes backlog items in light of the discussion. This collaborative reshaping is the review's real deliverable.
- Confirm the direction. The session closes with a shared sense of the likeliest next steps, giving the upcoming sprint planning a running start.
Notice that only the second step is the "demo." Everything around it — context, honesty about progress, feedback, and backlog adaptation — is what makes the meeting worth holding.
Sprint review vs. sprint retrospective
The sprint review and the sprint retrospective are the two events that close a sprint, and they are constantly confused — but they look in opposite directions. The review looks outward at the product with stakeholders; the retrospective looks inward at how the team works, on its own. The review comes first; the retrospective follows it.
| Sprint review | Sprint retrospective | |
|---|---|---|
| Focus | The product and the increment | The team's process and collaboration |
| Question it answers | Are we building the right thing? | How can we work better? |
| Who attends | Scrum team + stakeholders | The Scrum team only |
| Main output | An adapted product backlog | Actionable process improvements |
| When | Near the end of the sprint | After the review, closing the sprint |
The clean way to remember it: the review is about the product, the retrospective is about the team. One gathers outside feedback to steer what gets built; the other gathers inside reflection to improve how it gets built. Both are inspect-and-adapt events, but they inspect very different things.
Best practices and anti-patterns
The gap between a review that steers the product and one that wastes an afternoon comes down to a few habits:
- Only show "done" work. Demonstrating unfinished features invites feedback on something that doesn't really exist yet and erodes trust in what "done" means.
- Invite the right stakeholders. A review with no real customer or business voice in the room can't gather the feedback that gives it its purpose. Curate for signal, not size.
- Make it a conversation, not a presentation. Budget most of the time for discussion and feedback, not for a polished slide deck. Keep it informal.
- Actually adapt the backlog. The review should change something. If the backlog looks identical before and after, the feedback loop didn't close.
- Don't treat it as an approval gate. The review is collaborative steering, not a manager signing off on the team's work. The moment it becomes a gate, stakeholders stop giving honest feedback.
The recurring anti-pattern beneath all of these is the same: reducing a two-way working session to a one-way show. Guard against that, and the review becomes one of the highest-leverage hours in the sprint.
Sprint Review on the PMP® and CAPM® Exams
Because the current PMP exam emphasizes agile delivery and, above all, value delivery and stakeholder engagement, the sprint review is a natural fit for exam scenarios. The facts to lock in: it happens near the end of the sprint, is timeboxed, brings the team together with stakeholders to inspect the increment, and produces an adapted product backlog. The exam frames it as a collaborative, adaptive event — the project manager facilitates feedback and steering, never a top-down sign-off.
Situational questions tend to describe a review being used wrongly — as a status gate, a one-way demo, or an event where stakeholder feedback is heard but never acted on — and reward the answer that keeps it collaborative and lets feedback reshape the backlog. Watch for questions that test whether you can tell the review (product, with stakeholders) from the retrospective (process, team-only); mixing them up is a common trap. Our PMP Complete Study Guide, the most complete on the market, covers the agile events and the stakeholder-engagement mindset the exam rewards.
PMP Practice Question: Sprint Review
At a sprint review for a retail-analytics product, the demonstrated increment impresses a key customer, who asks on the spot for three new dashboard features and presses for a commitment that all three will arrive in the next sprint. The sponsor signals agreement, and the product owner, pleased with the goodwill, turns to the developers for an answer.
What should happen next?
a) Commit to the three features while the customer's enthusiasm is high, since responding quickly to customer needs is the heart of agility.
b) Have the developers estimate the three features before the review ends, so the customer leaves the room with a definite answer about the next sprint.
c) Welcome the requests and capture them as product backlog items to be refined and ordered by value, with the next sprint's scope decided at sprint planning based on the team's capacity.
d) Explain that the three features must first pass through the change control board, since adding them alters the release scope the stakeholders previously agreed.
Correct answer: C.
Rationale: The sprint review exists to gather exactly this feedback and adapt the product backlog — it is not a commitment ceremony, and the discipline is in the sequence: capture now, refine and order by value, and let the developers forecast at sprint planning, the event designed for that decision. Choice a) promises capacity nobody has measured, under social pressure, and trades the goodwill of this review for the credibility lost at the next one when three unexamined features do not all arrive; choice b) is the subtler version of the same error, manufacturing estimates in the glow of the room before refinement has asked a single clarifying question, and quietly converting the review into a planning session it was never meant to be; choice d) imports predictive change control into an artifact built to absorb change, treating the backlog as a baseline when reordering it is the product owner's routine job. The customer loses nothing in the correct path except an answer given too early. To face more questions that turn on sequence and event purpose, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is a sprint review?
A sprint review is the Scrum event held near the end of each sprint where the Scrum team and its stakeholders inspect the increment — the sprint's completed work — and collaborate on what to do next. Its main output is an adapted product backlog, reprioritized in light of feedback and any changed conditions. It comes just before the sprint retrospective.
What is the purpose of a sprint review?
The purpose is to inspect the increment with stakeholders, gather their feedback, surface any changes in the market or priorities, and adapt the product backlog so the next sprint reflects the latest reality. It is Scrum's checkpoint for confirming the team is building the right thing and adjusting course while the cost of change is still low.
Who attends a sprint review?
The whole Scrum team attends — the developers, the product owner, and the Scrum Master — along with key stakeholders invited by the product owner, such as customers, users, sponsors, and business representatives. The stakeholders' presence is what distinguishes the review from internal events like the daily standup and the retrospective.
How long is a sprint review?
A sprint review is timeboxed to a maximum of four hours for a one-month sprint, and proportionally less for shorter sprints — roughly one hour per week of sprint length, so about two hours for a two-week sprint. The timebox is a ceiling, not a target, and teams with a genuinely "done" increment often need less.
What is the difference between a sprint review and a sprint retrospective?
The sprint review looks outward at the product: the team and stakeholders inspect the increment and adapt the product backlog. The sprint retrospective looks inward at the process: the Scrum team alone reflects on how it worked and identifies improvements. The review is about the product and includes stakeholders; the retrospective is about the team and is internal. The review comes first.
Is a sprint review just a demo?
No. A demo — showing the completed increment — is part of a sprint review, but only the starting point. The review is a two-way working session where stakeholders give feedback, changes are surfaced, and the product backlog is adapted for the next sprint. A review that only shows work, without gathering feedback or changing anything, has missed its purpose.
Is the sprint review on the PMP exam?
Yes. The current PMP exam covers agile approaches heavily and emphasizes value delivery and stakeholder engagement, so the sprint review appears in scenario questions. You are expected to know it is a collaborative event that inspects the increment and adapts the backlog, and to recognize when it is being misused as a one-way demo or an approval gate.
Is the sprint review on the CAPM exam?
Yes. The CAPM covers the Scrum events, including the sprint review, usually a little more directly than the PMP — often testing its purpose, the timebox, who attends, or how it differs from the retrospective. Because the CAPM is scenario-based, you should also be ready to identify a sprint review that is being run incorrectly.
What Is Scrum? Roles, Events & Artifacts [2026]
Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
Product Owner: Role, Responsibilities & Skills [2026]
The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.
