How to Facilitate a Sprint Review
The Sprint Review is an opportunity for the whole Scrum Team to stand in front of their users, stakeholders and customers and inspect and adapt the Product. It takes place at the end of the Sprint. The meeting should include an overview of the state of the product in terms of progress, budget and next steps. Usually, there is also a hands-on demonstration of the actual product. The users and stakeholders provide feedback, and then the developers incorporate relevant feedback into the Product Backlog.
What is a Sprint Review?
The Sprint Review is the third one of the Scrum Events that takes place within a Sprint. The purpose of a Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. It takes place on the last day of a Sprint, and is timeboxed to a maximum of four hours for a one-month Sprint.
What does the Scrum Guide say about the Sprint Review?
The Scrum Guide defines the purpose of the Sprint Review as a chance to “inspect the outcome of the Sprint and determine future adaptations”.
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
Who should attend the Sprint Review?
The Sprint Review should be attended by the whole Scrum Team (Product Owner, Developers, and Scrum Master) as well as the customers, stakeholders and users.
What is the purpose of sprint review?
According to the Scrum Guide, “the purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations”. This is the key purpose of the event, and should be the focus. There are, however, a few other purposes and benefits to the event. Firstly, it enables you to improve your responsiveness to customers or users. Secondly, it helps with quality assurance, since your whole team and various other stakeholders will be present to inspect the product. Finally, it can help with team cohesion, as it’s a chance to get together and run through the various successes and challenges of the Sprint.
Sprint Review vs Retrospective
Since both events involve inspecting the completed Sprint and adapting for the future, some people get the two events confused. However, there are some key differences:
- The Review is attended by the Scrum Team, stakeholders, and users, while the Retrospective is exclusively attended by the Scrum Team;
- The purpose of the Review is to improve the product, while the Retro is more focused on improving effectiveness;
- The Sprint Review is timeboxed to a maximum of four hours for a one-month Sprint; while the Retro is expected to take less than three hours;
- The Sprint Review takes place on the last day of the Sprint, while the Retrospective takes place thereafter.
Photo by Jason Goodman on Unsplash
Tips to improve your Sprint Review
- Consider it a chance to collaborate with stakeholders (not just a demo)
- Get real users to give real feedback
- Collect the feedback (but don’t act on it yet)
- Create the right scenarios and focus on storytelling
- Have a vision (the “big picture”)
- Manage the backlogs
- Don’t throw your PO under the bus: nothing should be a surprise for them
- Let the team take charge
Sprint Review agenda
Below is a sample agenda or structure, which we use at agile42.
Introduction
The SM, who acts as a facilitator, introduces the event by welcoming the participants. They explain the purpose of the meeting to the participants which can include users, stakeholders and customers. Then they show the agenda for the meeting. (5-10 min)
Inspection phase
The PO takes the lead and provides an overview of the state of the product in terms of progress, budget and next steps. They remind everyone of the Product Goal and describe the Sprint Goal the Developers were trying to achieve. (10 min)
The PO leaves the stage to the Developers to demonstrate the Increment. This is not a PowerPoint presentation of what the team has done, but a hands-on demonstration of the actual product. Usually Developers will go through the scenarios described in the acceptance criteria of each PBI. Some teams even let users or customers try the product themselves, while the Developers and the Product Owner observe how they interact with the Increment. (30 min)
The Scrum Team collects feedback on the Increment from all invited participants. (15-30 min)
Adaptation phase
Users, stakeholders and customers might leave the meeting at this point, while the Scrum Team continues with a working session to incorporate relevant feedback into the Product Backlog. Should the feedback be related to something which does not impact the upcoming Sprint, they can simply take notes to address the feedback in one of the upcoming Product Backlog Refinement sessions. However, if the feedback potentially affects the next Sprint Goal, the Scrum Team will perform a quick Product Backlog Refinement session during the Sprint Review to get ready for the upcoming Sprint Planning. (30 min)
Closing
The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)
