Sprint reviewagenda, participants, and outcomes
Bring stakeholders together to inspect the Sprint outcome, discuss what changed, and decide how the product direction should adapt.
A Sprint Review is the Scrum event for inspecting the outcome of the Sprint and determining future adaptations. The Scrum Team brings its results to key stakeholders. Together, everyone discusses progress toward the Product Goal, changes in the environment, and the product decisions that come next.
The official Scrum Guide describes the Sprint Review as a working session driven by evidence and discussion.
Sprint Review at a glance
- Purpose: Inspect the Sprint outcome and determine future adaptations.
- Participants: The Scrum Team and key stakeholders.
- Position: The second-to-last event of the Sprint, before the Sprint Retrospective.
- Maximum timebox: Four hours for a one-month Sprint. Shorter Sprints usually use less time.
- Possible result: Shared understanding, decisions about what to do next, and Product Backlog adaptation.
The agenda below is a practical example for a shorter Sprint. Adjust it to the product, stakeholder group, and available evidence while keeping the Scrum timebox in view.
A practical Sprint Review agenda
| Step | Time | Working-session focus |
|---|---|---|
| 01Reconnect to the Product Goal | 5 minutes | Restate the Product Goal, Sprint Goal, and the decisions this review should inform. |
| 02Inspect the Sprint outcome | 20 minutes | Use the usable Increment and relevant evidence to examine the result, what the team accomplished, what it learned, and what those findings mean. |
| 03Discuss what changed | 10 minutes | Invite stakeholder context about users, markets, operations, risks, dependencies, and new opportunities. |
| 04Collaborate on what to do next | 15 minutes | Explore options and likely adaptations. Detailed selection and planning happen in Sprint Planning. |
| 05Summarize adaptations | 10 minutes | Confirm decisions, open questions, Product Backlog changes, and who will carry each follow-up. |
Prepare for inspection
Bring the usable Increment and evidence. Useful signals include observed customer behavior, support or operational learning, progress toward the Product Goal, changed constraints, and new opportunities.
Stakeholder collaboration happens throughout the Sprint. The Review gives the relevant people a regular point to inspect the combined result and update their shared understanding.
Who participates and what they contribute
- The Product Owner reconnects the discussion to the Product Goal and current Product Backlog.
- Developers make the usable Increment and key technical or delivery lessons open for inspection.
- The Scrum Master helps the event stay productive and within its timebox.
- Key stakeholders add product, customer, market, operational, regulatory, or organizational context that can affect the next decision.
These contributions give each participant a useful starting point. People respond to evidence and each other.
How a Sprint Review uses a demo
A demonstration makes the Increment concrete. The working session continues with questions such as these:
- What did this Sprint outcome teach us about progress toward the Product Goal?
- What changed for users, customers, competitors, operations, or the wider organization?
- Which assumptions now have evidence, and which remain uncertain?
- What opportunity, risk, or dependency should affect future ordering?
- What should the Product Backlog reflect after this conversation?
Keep polished slide presentations, sign-off decisions, and completed-ticket celebrations in their own meetings so Review time stays open for evidence and discussion. The Review needs its time for inspection and adaptation.
What can be inspected at the Review?
Work becomes part of an Increment when it meets the Definition of Done. Unfinished items return to the Product Backlog for future consideration, while completed Increment work is ready for inspection.
A usable Increment may be delivered before the Sprint Review. Release timing stays separate from the event. The Review brings the result, current context, and relevant people together so they can decide what they learned and what should change next.
Sprint Review versus Sprint Retrospective
The Sprint Review inspects the product outcome with key stakeholders. The Sprint Retrospective follows it and turns to the Scrum Team's interactions, processes, tools, and Definition of Done.
- Review question: What does the Sprint outcome and current environment mean for the product?
- Retrospective question: What should the Scrum Team change to improve quality and effectiveness?
Keep the events separate because they serve different decisions and participant groups. The Scrum event-order guide maps the Review, Retrospective, and next Sprint Planning from the end of the current Sprint into the beginning of the next one.
Close with shared understanding
Summarize the agreed adaptations, open questions, and the person carrying each follow-up. The Product Backlog may change as a result. A complete next-Sprint plan comes later during detailed selection and Sprint Planning.
After the product conversation, give the Scrum Team a separate space to improve its way of working before the next Sprint begins. The Sprint Retrospective guide has a focused agenda, examples, and ways to follow through.