The Sprint Review is one of the most valuable events for the Product Owner, because it is an opportunity for the Scrum Team as well as stakeholders/customers to inspect what was delivered, discuss what progress has been made towards the Product Goal, and adapt accordingly. The Sprint Review should not be treated as merely a demo (although a demo may be on the agenda). Instead, this is a key inspect and adapt event where feedback is gathered which the Product Owner may use to update the Product Backlog and Product Forecast.
I am often asked, is there a timebox for the Sprint review? The answer is YES! Absolutely! The timebox for the Sprint Review is four hours (and honestly, I have never been to a Sprint Review that long even for a team using Nexus to scale multiple Scrum Teams.) This timebox exists to respect the time of attendees and to ensure that the meeting remains productive.
Preparing for the Sprint Review Event
Key inputs into the Sprint Review event include the Product Goal, the Increment, the Product Backlog, the Forecast (or Roadmap), the Definition of Done, the Sprint and any market changes.
Product Goal
Without a Product Goal, the Scrum Team is like a ship without a rudder. The Product Goal is owned by the Product Owner. There can be only one Product Goal at a time in order to give focus to the team.
The Increment
According to the Scrum.org glossary, the Increment is the “Scrum Artifact that defines the complete and valuable work produced by the Developers during a Sprint. The sum of all Increments form a product.” The Increment is what is delivered by Developers each Sprint. The purpose of the Sprint is to create a done, usable increment each Sprint.
Product Backlog
The Product Backlog is owned by the Product Owner and is the single source of requirements for the Scrum Team. The Product Backlog needs to be transparent and available to all, and should show what the Scrum Team will work on next.
Definition of Done
The Definition of Done describes all of the work that needs to be completed for each Product Backlog Item before it can be considered done. The Definition of Done guides the Scrum Team when they are determining what work to pull into the Sprint, and it provides context to the Product Owner as well as stakeholders so that they understand what level of work has been put into each Product Backlog Item before it is discussed at the Sprint Review meeting.
The Sprint
The Sprint Goal as well as the Product Backlog Items planned/delivered as part of the Sprint are a key input into the Sprint Review meeting.
Forecast
The Forecast shows delivery or release dates for the Product. There are many different ways to share a forecast, including a Roadmap or Monte Carlo diagram.
Market Changes
Prior to the Sprint review, the Product Owner should gather information on any relevant Market changes which could impact the Product.
What happens at the Sprint Review
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment or the Marketplace. Based on this information, all attendees at the Sprint Review collaborate on what to do next. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation or team building event.
Product Goal
In order to keep the team heading in the right direction, the Product goal should be reiterated at every opportunity, including the Sprint Review. This is an opportunity to remind both the Scrum Team and the Stakeholders what we are aiming to achieve as a way to focus the conversation on what matters.
Sprint Goal
At the Sprint Planning meeting for each Sprint, the Scrum Team creates a Sprint Goal which describes WHY the Sprint is being delivered. Ideally, each Sprint should be a step towards the Product Goal and should describe the highest ordered Product Backlog items which were pulled into the Sprint.
Review Market Changes
Any Market changes which may impact the Product should be presented at the Sprint Review meeting. This information will help the Scrum Team and its stakeholders to better provide feedback and better understand the Product Owner’s reasoning behind the order of Product Backlog Items in the Product Backlog.
Explain what was done and not done
For Transparency, the Scrum Team may choose to describe which Product Backlog items were originally planned for the Sprint, and which of those Product Backlog items were done - or not - by the end of the Sprint. This level of Transparency can be uncomfortable for teams, but it provides stakeholders with key insights into the issues which the team is facing and may be an opportunity for the Scrum Team to request assistance with removing impediments.
Demonstrate working software (or the Increment)
For software development Products, the team may choose to provide a live demonstration or a presentation of the done increment in order to give stakeholders and opportunity to react to what was done and to provide feedback. You do not need to demonstrate every single Product Backlog Item which was delivered as part of the Sprint, but be sure and cover the most valuable Product Backlog Items which were delivered. Frequently, the Developers facilitate this part of the Sprint Review meeting because they are closest to the work and best able to answer any questions that may arise.
Collect Feedback
This is the part of the Sprint Review that is most frequently skipped for newer teams. Many teams do not do enough to encourage sprint review attendees to provide feedback.
Review Forecast
The Sprint review might conclude with a discussion of the Product Forecast. The Forecast is a prediction of what features or functionality might be delivered next, and when.
Outputs from the Sprint Review
Coming out of the Sprint Review, the Product Owner should be able to update the Product Backlog (including detail and ordering) and the Forecast based on feedback received.
Conclusion
The Sprint Review is an important inspect and adapt opportunity. In order to get the most from this meeting, attendees should be limited to the Scrum Team and important stakeholders who are invited to provide direct feedback. If the meeting is too large, individuals may hesitate to provide honest feedback. If the meeting is too small, then it’s a missed opportunity to gather feedback from stakeholders which could be used to maximize the value of the product resulting from the work of the Scrum Team.
Comments