Sprint reviewagenda, participants, and outcomes
Inspect the Sprint outcome with stakeholders, discuss what changed, and adapt the product direction in a collaborative working session.
A Sprint Review is the Scrum event for inspecting the outcome of the Sprint and determining future adaptations. The Scrum Team presents the results of its work to key stakeholders, everyone discusses progress toward the Product Goal and changes in the environment, and the attendees collaborate on what to do next.
The official Scrum Guide describes the Sprint Review as a working session and says the Scrum Team should avoid limiting it to a presentation.
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 evidence available rather than treating the timing as an additional Scrum rule.
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 what was accomplished and learned. |
| 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 without turning the event into detailed Sprint Planning. |
| 05Summarize adaptations | 10 minutes | Confirm decisions, open questions, Product Backlog changes, and who will carry each follow-up. |
Prepare an outcome people can inspect
Bring the usable Increment and the evidence needed to understand its outcome. That might include observed customer behavior, support or operational learning, progress toward the Product Goal, changed constraints, and new opportunities.
Do not save every useful conversation for the event. Stakeholder collaboration happens throughout the Sprint. The Review creates a regular point where the relevant people inspect the combined result and adapt their understanding together.
Who participates and what they contribute
- The Product Owner can reconnect the discussion to the Product Goal and the current Product Backlog.
- Developers can make the usable Increment and important technical or delivery learning inspectable.
- The Scrum Master helps the event remain productive and within its timebox.
- Key stakeholders contribute product, customer, market, operational, regulatory, or organizational context that can affect what happens next.
These are useful facilitation contributions, not a script that assigns every sentence. The event works when attendees collaborate instead of taking turns reporting to one another.
A Sprint Review is more than a demo
A demonstration can make the Increment concrete, but demonstration alone does not fulfill the event’s purpose. A useful Review also asks:
- 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?
Avoid turning the event into a polished slide presentation, a sign-off meeting, or a celebration of completed ticket counts. The aim is inspection and adaptation, not approval theater.
What can be inspected at the Review?
Work is part of an Increment only when it meets the Definition of Done. Items that do not meet that definition return to the Product Backlog for future consideration; they should not be presented as completed Increment work.
A usable Increment may be delivered before the Sprint Review. The event is not a release gate. Its value comes from bringing the result, current context, and relevant people together to decide what has been 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 inspects how the Scrum Team worked across interactions, processes, tools, and its 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 shows exactly how the Review, Retrospective, and next Sprint Planning fit together.
Close with shared understanding
Summarize the adaptations attendees agreed to, the questions that remain open, and who will carry each follow-up. The Product Backlog may change as a result, but the event does not need to produce a complete next-Sprint plan. Detailed selection and planning belong in Sprint Planning.
After the product conversation, give the Scrum Team a separate space to improve its way of working. Use the Sprint Retrospective guide for a focused agenda, examples, and follow-through.