Scrum Events: Sprint Review (Demo)
Do you get enough feedback from your stakeholders and customers? Do you feel like you’re shipping great software every week, but nobody knows what you’re doing? Do you feel out of touch with what your teams are working on?
Then the Sprint Review—also known as the Sprint Demo—is for you. This 3-minute video will give you an overview of the Scrum event, along with some tips and tricks I’ve learned along the way.
Sprint Review is held at the end of every sprint to celebrate the team’s success, inspect the product increment delivered by the Development Team, and adapt the product backlog as needed. It is also an opportunity for the Scrum Team to demonstrate transparency about their output and process to their stakeholders so as to foster mutual trust.
The event is attended by the entire Scrum team and the stakeholders and customers invited by the Product Owner. Some teams find it useful to complete their first Review or two privately so that they can get the hang of it before inviting stakeholders and customers as stakeholders who attend many disorganized events may not come back for more.
Here’s a sample agenda that covers the most important points of a sprint review.
First, the product owner welcomes their stakeholders and explains what product backlog items have and have not been fully completed.
Second, the development team briefly talks about their experiences during the sprint, including any impediments that arose and how they resolved them. Note that most teams complete their sprint retrospective event after the sprint review so that they can include what happened at sprint review in the retrospective, so be aware that you may not have the most refined responses yet. Also, this isn’t an opportunity for stakeholders to criticize the team’s process. If a stakeholder has this type of concern, they should discuss it with the Scrum Master and/or Product Owner after the event.
Third, the Development team demonstrates each completed backlog item, ideally from the end-user’s perspective: show results, not code. Demonstrating backlog items on staging can illustrate that the work integrated correctly. While demonstrating from production is nice, it is not necessarily required.. Stakeholders should be encouraged to ask questions and provide feedback; anyone on the team can answer.
Fourth, the product owner can share forward-looking updates. What is the current state of the backlog? Have any longer-term forecasts, such as release date and scope, changed?
Fifth, all attendees participate in an adaption exercise: having inspected the product increment and backlog presented transparently by the Scrum team, what adaptations would should we make? It can also be helpful to talk about changes in the market or other team-external events that could impact the team’s future plans.
The primary output of the Sprint Review is an updated product backlog that reflects the event.
This event can take up to one hour per week of iteration, but most teams and stakeholders will want to complete it in less time, typically 30-60 minutes for a 2-week sprint.