Stephen Turner
Akash Kumar
Jordan Lee
Taylor Scott
How to run a Sprint Review that helps decide what comes next
A Sprint Review brings the Scrum Team and key stakeholders together to look at what the Sprint produced and decide what to change next. Its value is in learning what the results mean for the product and agreeing the next steps together.
Keep the purpose of the event
The Scrum Guide calls the Sprint Review a working session, not just a presentation. The team and stakeholders discuss results, progress toward the Product Goal and changes around them. That discussion can reshape the Product Backlog.
It lasts at most four hours for a one-month Sprint, usually less for shorter ones. It isn't a gate for releasing work. The agenda below is a suggested format that fits within those rules.
Prepare something stakeholders can try
Say a support-portal team has finished a request-tracking flow. Prepare it with a realistic example ticket. Explain the customer problem it solves and what the team still wants to learn. Keep what you can demonstrate apart from guesses about how customers will react.
Invite stakeholders with relevant experience. Here, that means someone who handles support requests and someone who owns customer communication. Share the question you want help with beforehand. If someone can't attend, collect their input in advance and say who will raise it.
A 60-minute working agenda
Adjust the timing to your Sprint and the work. Leave real time for discussion. A polished demo followed by one rushed question at the door won't teach you anything new.
| Time | Activity | Capture |
|---|---|---|
| 5 minutes | Reconnect the results to the Product Goal | The question this work addresses |
| 15 minutes | Inspect completed work using a realistic scenario | Observed behavior and uncertainties |
| 20 minutes | Discuss stakeholder feedback and changed circumstances | New information affecting the product |
| 15 minutes | Explore possible adaptations | Candidate backlog changes and trade-offs |
| 5 minutes | Confirm what needs follow-up | Owners for unresolved evidence or questions |
Example: a finished feature reveals another problem
The team demos the new tracking page. A support lead tries it and points out that customers usually reply to an old email thread instead of returning to the portal. Another stakeholder adds that confirmation emails hide the tracking link. The feature works, and the team has learned why the workflow might still fail.
Options include fixing the confirmation email, studying how people return to tickets or improving an existing entry point. Record each with its reasoning. Don't treat the first idea as a promise for next Sprint; the Product Owner weighs it against other needs.
Ask questions that get useful answers
Ask people how the result fits their actual work. “Where would this request go next?” gets further than “Does everyone like it?” When someone makes a broad claim, ask for an example. Note whether it's something they've seen or something they expect.
Keep feedback tied to the product question, and leave detailed design for later. If needs conflict, record both and what choosing between them would mean. Don't record an agreement nobody reached.
- What would someone need before using this result?
- Which changed circumstance could affect its usefulness?
- What evidence would help us choose the next adaptation?
Follow up on the product, not the team
Afterwards, keep a short record of what you reviewed, key feedback, possible changes and open questions. Put a name next to each piece of evidence to collect. A changed priority or a clearer unknown is a good outcome. You don't need everyone to approve.
If you record the review in Bridge, the notes give you a summary, decisions and follow-ups to start that record from. Share them with stakeholders who missed it, by email invite or with the workspace.
Don't let the review turn into a team performance review. Problems with how the team works belong in the Sprint Retrospective. Atlassian draws the same line: the review covers the product and stakeholder feedback, the retrospective covers how the team works.