The Sprint Review is the oldest event in Scrum. It exists since the very beginning of Scrum, in 1995. Many things would change in Scrum. Events would be added, like the Daily Scrum, Sprint Planning and Sprint Retrospective. The Sprint Review has been there all the time.
The Sprint Review is a crucial event in Scrum. It is the moment when the Scrum Team and its stakeholders inspect the outcome of the Sprint and decide what to do next. The Scrum Team provides transparency by presenting the result of their work. They then inspect these results with key stakeholders and adapt based on their shared insights.
Transparency, Inspection and Adaptation. The empirical pillars of Scrum. Outside of Scrum, there are different but similar learning loops:
Back in 1995, Scrum called it Develop, Wrap, Review, Adjust
Heart of Agile has Collaborate, Deliver, Reflect, Improve
Lean Startup has Build, Measure, Learn
You may know more examples. My point is to clarify how essential this learning loop is for Scrum and other modern-day approaches. This is why I find it heartbreaking how often the Sprint Review is misused or neglected.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fc39e5045-08ec-4b23-b163-e0b708af90b3_6000x4000.jpeg)
Sprint Review - Signs of trouble
There’s no one right way to conduct Sprint Reviews. But there are all kinds of signs of trouble:
The Sprint Review takes half an hour at most. There’s not much to discuss. If you address everything a Sprint Review should entail, then I argue you will need more than half an hour.
Sprint Reviews are regularly skipped. A common reason I know is that the team has nothing to show. Even if you don’t have anything to show, you want to share and learn new insights to understand what to do next.
Stakeholders don’t show up or “have to” attend because they are expected to do so. It appears the stakeholders don’t know their crucial role in the creation of the product.
The Sprint Review is a presentation of the Product Owner with occasional questions and answers. This way, there’s no learning opportunity.
Or, in contrast to the previous point, the Sprint Review is a demo only with the intention to sign off the work of the developers. Also here, there’s no true learning. It’s just checking if the team did what they should do.
Sprint Reviews only look back. The next Sprint or future Sprint aren’t discussed. You wish to have the desired future state of the product in mind and a rough idea of how to get there.
What is the true meaning of the Sprint Review?
The purpose of Scrum is to create value when the product environment is complex and you don’t know what will happen. Scrum is built upon empiricism. You may have assumptions you wish to verify by building increments of the product, inspecting them with the key stakeholders and adapting based on observations.
When you work with Scrum, the Sprint Review can’t be wasted. In complex environments, you can’t rely on detailed plans that span multiple months. You need to adapt to stay on track towards your goal. The insights you gain from the Sprint Review help you to make these adaptations.
The Sprint Review should revolve around your long-term desired outcome. It should be about “what can we learn now that helps us to decide what we should do next to create the achieve the desired value from the product?” The long-term desired outcome is formulated in the shape of a Product Goal.
In ever-changing environments, you need to get key information on the table. Here are examples:
Does the product increment created by the team in the past Sprint work as desired? Not that showing the product increment may lead to new insights. Because a working product removes possible differences in interpretations you have by only talking about requirements.
Do we have feedback from users? How do they like our product?
Do we have other information showing us how well our product is received?
Does the current product meet our financial expectations? If not, what should we do to improve this?
What are the developments in the market? What does our competition do that may impact our decisions?
Are there new technology developments that impact our decisions?
In short, any news that may impact your next steps should be on the table at the Sprint Review.
Where do you get this information from? And how are you going to weigh all of this? Well, by inviting the people to contribute to the Sprint Review. Every product environment is different. So key stakeholders differ per team. But you may want to think about having users, customers, finance, risk management, sales, operations, and/or suppliers at the table. Suffice it to say, this is not a conclusive list.
Step by step towards effective Sprint Reviews
Many teams are far removed from an effective Sprint Review. And this is a problem when you wish to use Scrum to create value in a complex environment.
Here’s how to move to effective Sprint Reviews step by step:
Identify the key stakeholders of the Scrum Team. Who are the people that have vital information about aspects that impact what you need to do next and who have a vested interest in the product you are creating?
Help the Product Owner, Developers, and key stakeholders understand the purpose of Scrum. I personally have achieved the best results by discussing the traits of a complex product environment, discussing empiricism and how the Sprint Review fits in this. It is vital to not only help the team but also the key stakeholders. The need to play an active role during - especially - the Sprint Review.
Define a Product Goal that clearly depicts the desired future state of the Product.
Arrange your Product Backlog to optimize the chances to achieve the Product Goal.
Have the key stakeholders in the Sprint Review.
Aim to build a working piece of product every Sprint with the purpose of reviewing it and learning from it.
At the Sprint Review, discuss the current Product Backlog and the Product Goal.
At the Sprint Review, inspect the working piece of software at the Sprint Review, having the Product Goal in mind. The aim is to understand how the increment helps to move towards the Product Goal.
At the Sprint Review, facilitate the discussion about other factors that may impact the progress towards the Product Goal. These could be user feedback, financial information, market developments, and technology developments.
At the Sprint Review, update the Product Backlog based on the newly gained insights.
At the Sprint Planning, use the updated Product Backlog and learnings from the Sprint Review to decide what is the next step towards the Product Goal.
Rinse and repeat.
Suffice it to say, this will hardly fit in a half-hour meeting!
Typically this is the job of a Scrum Master to help the team and the stakeholders to understand Scrum and their role in the framework. The Product Owner is the logical choice to be responsible for stakeholder management. However, others in the team could do this too.
Power to the Sprint Review!
I hope I was able to convince you of the importance of the Sprint Review. As I see it, it is the bread and butter of Scrum. It was the first event in Scrum back in 1995 and it continues to be vital.
Scrum is about developing a product in increments that are inspected with the stakeholders every Sprint. If you have an ineffective Sprint Review, you will be ineffective as a Scrum Team.
My twelve steps to improve the Sprint Review is a journey. It takes time to coach the team and stakeholders and to have effective Sprint Reviews. Time and patience. But I can assure you, once you have the key stakeholders at the event, collaborating to inspect what was learned and what to do next, you will drastically improve your capacity to create value.
Good read !!