Any phase · Ways of working
Run a sprint review
At the end of each sprint, the team shows what it built to stakeholders and discusses what to do next. It is a working session, not a presentation.
About 1-2 hoursEvergreenLast reviewed 5 November 2026
Who this applies to
- Skills it builds
- Delivery and executionCommunication and influence
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- Scrum
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- Invite stakeholders and some users if possible.
- Remind everyone of the sprint goal.
- Show working product, not slides.
- Ask for feedback and questions.
- Discuss what to do next and update the backlog.
- Keep it to about an hour for a two-week sprint.
Intermediate (1 to 4 years)
- Demo working software against the sprint goal.
- Gather feedback and adjust the backlog.
- Share progress towards the product goal.
Experienced (5+ years)
- Use reviews to keep stakeholders engaged and aligned.
- Show results and data, not just features.
- Invite real users to give feedback.
Who can do this
Owner: Product manager
Can be delegated to
- Scrum Master or Delivery Manager: Organise and facilitate the review
- Full-stack Engineer or Frontend Engineer or Backend Engineer: Demo the work
Reviewed by: Scrum Master
Tool examples
- Jira
- Show the sprint report and completed items.
- Confluence
- Record feedback and decisions on a review page.
- Figma
- Show upcoming designs to get early feedback.
Definition of done
- Working product demonstrated
- Feedback gathered
- Backlog updated
Common pitfalls
- Slides instead of working product
- Only the team attends
- No changes made from feedback