💡 The purpose of the Sprint Review is to show work completed in the last sprint and gather customer feedback to adapt the Product Backlog.
Sprint Review is the second to last meeting that happens at the end of the Sprint. Usually on the last day of the Sprint, right before the Retrospective.
Maximum duration: 4 hours (for 1 month sprints) as per the Scrum Guide.
Recommended duration: 1-2 hours for 2 weeks Sprints depending on how many teams present at the same time.
Agenda #
- Review the work that has been done last sprint (meets the Definition of Done)
- Collect feedback about the current state of the product from stakeholders and customers
- Review progress towards the Product Goal and likely completion dates (this should be updated every Sprint based on velocity and current Product Backlog)
- Discuss any impediments, dependencies, or other challenges that were hindering team’s progress
- Review the current Product Backlog and collaborate with stakeholders to agree on a plan for the future
Attendees #
The whole Scrum Team (Scrum Master, Developers, and Product Owner), stakeholders and other interested parties who will benefit from reviewing the product
Who leads the meeting: Usually this meeting is led by the Product Owner as the key customer representative. But presentation of the completed work is usually best done by the Developers.
Preparation #
Preparing for the Sprint Review is even more important as it includes our stakeholders and customers. Since it is often difficult to get their time and attention, prepare your Sprint Review to make it productive for everyone attending:
- Review the list of invitees and add people if you believe someone is missing. Maybe the team was working on a particular feature this Sprint that is interesting to just a small group of people, who might not be on the regular invite
- Get ready for the presentation part of the review where Developers demonstrate what was done. It doesn’t mean that the team needs to create actual slides to show, but the team should have a clear agenda, order of presentation, etc.
- The team might want to do a dry run to get ready. Since stakeholders attend Sprint Reviews, it’s important to have a concise and clear presentation to keep them engaged.
- It might make sense to review the Product Backlog and make sure it’s up to date. The team might have an overall idea about what they are most likely to work on next Sprint.
- The Product Owner may want to prepare a forecast, a roadmap, or a graph showing progress toward the Product Goal, a release date, etc.
Example #
- The Product Owner opens the meeting, greeting the attendees.
- Then the attendees review the past Sprint Goal and Sprint Backlog. The Product Owner highlights what the team wanted to get done and what they were able to accomplish.
- The Scrum Master highlights any challenges the team has been facing and requests help from the stakeholders if relevant.
- The Developers present the work completed. Only fully Done work is shown. The Developers show the product itself and features developed in action, not just screenshots or a PowerPoint presentation.
- The Scrum Master and the Product Owner encourage the stakeholders to give feedback.
- The stakeholders ask questions, raise any concerns, and give their general feedback on what has been presented. The team takes note of anything that impacts their Product Backlog.
- The Product Owner shows the progress toward the Product Goal or release dates and other milestones as well as what the team is most likely to be working on next Sprint.
- The stakeholders provide feedback about the progress and confirm that the current plan and the Product Backlog are aligned with their expectations. If not, the team discusses what needs to be changed and how it will affect the next Sprint.
