Skip to content

Sprint Review is more than a Sprint Demo

Imagine you and your team, in a room with 90 people demonstrating you work. People are quietly listening, there are no questions asked and once you are completed with the demonstration, people leave. There is zero engagement in the room. You have no idea whether your work or your demonstration was of any value. A sprint review is more than a sprint demo.

In this article I will share what is a sprint review? What is the time box? Who are the participants? What is the agenda and how to facilitate a sprint review?

A Sprint Review is more than a Sprint Demo

Anil Jaising
Geoff Watts Tweet on Sprint Review

Scrum is all about delivering value in small cycles of a month or less. Well how do you know if you are delivering value every cycle? The sprint review is your opportunity to ensure your product is meeting and exceeding customer expectations. 

Why do Most Teams Stumble in Sprint Reviews?

Firstly, there are misaligned expectations. There is no clear information about progress and no product increment (deliverable). Instead the team and the stakeholders are focussed on how much each member of the team delivered. The questions are asked on the overall velocity of the team.

Gunther Verheyen on the focus on velocity at sprint review

Secondly, lack of stakeholder engagement also plays the villain. If key stakeholders skip the sprint review, valuable perspectives are lost. The team misses out on crucial feedback that could guide the product’s direction.

I was working with a team where the Product Owner in Sprint planning would share what needs to be done. They then disappear for the entire sprint and then show up at sprint review. This is the first time the product owner is witnessing a demo shared by the developers. Although the product owner represents the stakeholders and customers, they are part of the scrum team. The more effective Scrum teams involve the product owner continually throughout the sprint, getting feedback on features in real time. Most mature teams that I have worked with the product owner and the team are sitting side by side. The sprint review is a Stakeholder Event.

Thirdly, the scrum team might treat it just as a one way demo. Demonstrate what they delivered, get no feedback and continue on with their original plan. They do not know what has changed in customer needs or market demands. A sprint review is more than a sprint demo.

Sprint Review Timebox

According to the Scrum Guide, A Sprint Review is up to 4 hours for a one month Sprint. Remember every event in Scrum is up to a certain maximum time. The event should be facilitated so that the agenda can be achieved in the least amount of time.

Sprint Review Participants

The Sprint Review is a meeting best facilitated by the Product Owner. The Product Owner should invite the Developers, Scrum Master and the Stakeholders.

How would you facilitate a Sprint Review?

Below is a step by step breakdown of the agenda along with a chain of simple facilitation technique for each step

Review the Completed Sprint

TopicParticipantsTime boxFacilitation Technique(s)
The Product Owner shares the Product Goal and the Sprint GoalProduct Owner and StakeholdersUp to 10 minutes1-2-4-All Discuss the sprint goal and discuss how it might meet customer and/or market needs
The Product Owner shares progress of the workProduct Owner and StakeholdersUp to 15 minutesThe Product Owner shares what was planned and what was done. Using Visual Reports like a Sprint Report and the Release Burn up. Besides progress data, the product owner can also share usage and other product related metrics.
The Developers demonstrate the “done” work and answer any questionsDevelopers and StakeholdersUp to 1 hourGallery Walk or World Cafe to demonstrate work potentially using different “workstations” and gathering feedback and insights about the demonstration.
The Developers share the problems they encountered while building the productDevelopers and StakeholdersUp to 15 MinutesContinue the above facilitation technique by adding more about problems and challenges, creating further dialogue among the stakeholders
The group together looks at marketplace changes or customer use. Review of the timeline and budget and review the anticipated release and capabilities of the productScrum Team and Stakeholdersa technique like the 15% solution from Liberating Structures and/or splitting people into groups and doing a group share and rotating the group members every 15 minutes to review and discuss potential future is a great way to keep people engaged and reviewing multiple dimensions.

Look at the future

TopicParticipants Time boxFacilitation Technique(s)
The Product Owner discusses the current state of the product backlog and projected release dates based on progressProduct Owner and StakeholdersUp to 15 MinutesLooking now to the current state and the future. The Product Owner can share a view into the Product Backlog and the Release Plan
The group together looks at marketplace changes or customer use. Review of the timeline and budget and review the anticipated release and capabilities of the productScrum Team and StakeholdersUp to 45 MinutesUsing a technique like the 15% solution from Liberating Structures and/or splitting people into groups and doing a group share and rotating the group members every 15 minutes to review and discuss potential future is a great way to keep people engaged and reviewing multiple dimensions.

Common Myths

Common questions in my training

Do the stakeholders need to attend? Isn’t the product owner enough?

The product owner is part of the scrum team, they collaborate with the developers at every step in the sprint. The product owner should familiarize themselves with the work delivered. At the Sprint review, stakeholders gain transparency into the team’s progress; this event marks the first time they observe the work completed and delivered. They also contribute to steering the deliverable in the right direction, based on customer feedback or market trends.

Do we have to have something to show every sprint review? What if the team worked system optimizations that cannot be shown.

The answer to the question is yes you should demonstrate what was delivered. The reason for the backend work might be due to a change in how the product performs or optimizing something that was working but now works better. If so can you describe the improvement and the outcome and demonstrate the product to show that outcome. Perhaps the whole system got faster, or something that can handle more users. Although the stakeholders might not be able to see visible differences, your explanation of the improvement along with the demonstration will make it real for the stakeholders and once they see something real they will have feedback.

Conclusion

The agenda and the facilitation technique can be adapted to suit your team and number of people attending your sprint reviews.

The facilitation techniques can be used both in-person and with remote and hybrid teams. We share several teaching and facilitation techniques in our Virtual Trainer Series

Share with me in the comments, what else would you like to see in this article that will help you improve Sprint Reviews with your team and in your organization.

Join our next training for the Certified Scrum Master® or the Certified Scrum Product Owner® class or any of the advanced class series. Our Training Calendar is available at https://conceptsandbeyond.com/training-calendar/

Join the conversation

Your email address will not be published. Required fields are marked *