The Scrum Sprint Review — Stage 6
The sprint review is a scrum event and Stage 6 of the roadmap to value. This scrum event is integral to the inspect‐and‐adapt process of scrum, and takes place at the end of each sprint.
The purpose of the sprint review is for the product owner to get organizational feedback on whether they are moving the product in the right direction. It is also a great opportunity for the “talent” (development team) to stand up and show off what they’ve accomplished. They get full credit for what they’ve achieved, and what they haven’t.
Empirical exposure modeling goes back to the beginning of time. However, somewhere along the way, it got lost in project management frameworks. Agile practices and scrum have brought it back with a roar. The entire sprint process — from sprint planning to the daily scrum and now the sprint review and sprint retrospective — reaps the full benefits of the empirical model and its premise of inspect and adapt.
This meeting at the end of each and every sprint ensures that the stakeholders are completely up to date on what was accomplished in the sprint and have a fantastic forum for delivering feedback directly to the product owner, with the development team listening in. As well, stakeholders now have working, “shippable” product in their hands.
The sprint review process
The sprint review is timeboxed to one hour per week of sprint, and it takes place at the end of the last day of the sprint, usually a Friday. So if your sprints are one week in duration, you would allocate one hour each Friday afternoon. Remember to allow for this time expenditure during the sprint planning session.
The participants in the sprint review are the entire scrum team and the stakeholders, in these roles:
Scrum master: Facilitates the meeting and ensures that it stays in focus and on time.
Product owner: Briefly reviews the sprint goal and how well the scrum team met the goal, fills in the stakeholders on what items from the backlog have been completed, and summarizes what’s left to go in the release.
The sprint review is not the place for the product owner to provide feedback on the completed functionality. It is for the product owner to receive feedback from the stakeholders on the direction that they are taking the product. The product owner accepts or rejects each requirement, as it is completed, not at the end of the sprint. The product owner approves the requirements before they’re demonstrated to the stakeholders.
Development team: Displays and explains the completed requirements.
Stakeholders: Ask questions and provide feedback.
The process begins with the development team preparing for the review. Consider the following guidelines for sprint review preparation:
The development team prepares for the sprint review in the minimal amount of time (20 minutes max) and without presentation material to showcase the requirements that they’ve completed.
No formal slides should be used in a sprint review.
The development team should spend as much of their time developing the product as possible rather than preparing theatrics.
Only the requirements that have been deemed “done” (according to the definition of done) and approved by the product owner are demonstrated.
The development team showcases the “shippable” functionality of the requirement, that is, how it works in the real world.
If you spend time showing stakeholders what could or should have been done, that means you’re giving a rigged demo, and you haven’t done anyone any favors. Stakeholders never expect less; they always expect more. By making it look like your product increment works when it really doesn’t, you’ll have increased your workload for the coming sprint, because you’ll have to make work what you showed should work, plus all the new work you’ll plan for. Demonstrate working product increments only. No rigged demos! They take time to create and that is valuable time away from development.
Critical to the success of the sprint review is stakeholder feedback. It’s this constant cycle of communication that keeps the project on track and producing what the stakeholders want. While stakeholders can’t tell development team members how to develop requirements, they can provide insight on which requirements and features they want developed to the product owner, and how well the implementations serve the customer’s needs.
This feedback loop serves another purpose as well: It keeps the development team involved and therefore emotionally engaged in the project.
When Daniel Pink studied motivation, he found that one of the three key elements was having a sense of purpose in what people were doing. Showcasing the developers’ hard work and being directly involved in feedback and planning help do just this. It’s called ownership.
Feedback is a common theme throughout scrum. The figure illustrates just how many different layers of feedback are involved in the scrum framework. Each time feedback is received, it gets cycled back into the product backlog and sprint planning sessions. This is truly inspect and adapt.
The product increment is the final of the three scrum artifacts.
Within a single sprint, the product increment is working product deemed done by the product owner and is now potentially “shippable.” It’s potentially shippable because the product owner may not decide that it’s ready to ship until a later date. But the good news is that it’s ready to ship as soon as the product owner is ready.
A product increment has been
During the sprint review meeting, this product increment is what is demonstrated to stakeholders. The inspect‐and‐adapt sprint life cycle continues as feedback is taken and translated into requirements. These requirements may then get elaborated during product backlog refinement activities, as they rise in priority for consideration in future sprints and eventually become new product increments.
The sprint review is about improving the product. Here’s how scrum teams can make this continuous improvement happen for their team and process.