So, a sprint review is not only a demonstration of the work that has been achieved by the team over the period of the sprint, but also a celebration of the great work that the team have produced and an opportunity to get feedback on the product.
What I really want to see from a sprint review is the team getting together and speaking about what they thought they could achieve versus what they did achieve.
We thought this was going to happen but in fact, this happened. These are the things that worked, and these are the areas where things went wrong.
Often things change over the space of a sprint.
The team analyse what was achieved, what wasn’t achieved, and the reasons for why certain things didn’t happen as anticipated.
It isn’t the time to whinge or complain, instead it’s an opportunity to let stakeholders know that things are not perfect within the organisation.
Maybe those stakeholders can give you a hand.
The team are in essence communicating what they have attempted, and they are communicating that those attempts have been unsuccessful. They can actively ask for the assistance of stakeholders to remove impediments to progress and the achievement of sprint goals.
Sprint reviews are a great opportunity to update product stakeholders on what is happening within the organisation. Stakeholders may be unaware of the problems that are faced and can actively contribute to ensuring that the team receive the support and resources they need to achieve their sprint goals and objectives.
Sometimes it’s a matter of organisational decision-making that prevents the team from achieving their sprint goal. Stakeholder awareness of how their decision-making impacts the team can actively help them improve in that area and serve the team through faster and better decision-making.
The sprint review is also an opportunity to show stakeholders what you have made.
I love it when scrum teams are confident enough to give stakeholders the reigns and empower them to actively engage with the product and understand why the features and improvements that have been built are going to be valuable to customers.
Allowing them to play with the product and seeing for themselves whether it does what the stakeholders wanted it to be able to do. Allowing them to see whether the product works the way they had hoped it would.
Through this process of engagement and interaction, great discussions can be initiated.
You can gain insights into whether the product is fulfilling its role within the big picture of the organisation and whether you are meeting stakeholder expectations. You can receive feedback on what stakeholders love about the product and which changes or improvements they would love to see.
In some cases, you are going to see new backlog items being created and in other circumstances you will see the prioritization of backlog items change based on the feedback and experience of the product stakeholders.
The conversation is vital to the success of the product and the reprioritization of backlog items is a great sign that you have a healthy development process and that stakeholders are confident enough to interact and engage with the team on the elements that most matter to them.
Once you’ve worked through the engagement with the product, you’re going to be having discussions around the future. You’ll be providing insights into what the next sprint looks like and what the focus of the work is going to be.
You’re going to be asking stakeholders what they think of the evolution and whether that aligns with what they feel is most valuable to customers and other stakeholders.
Sometimes, you’re going to have all stakeholders fully onboard whilst at other times you’re going to receive feedback from them that leads you in a different direction or onto an idea that everyone agrees will best serve the team in the following sprint.
Stakeholders will also be able to guide you as to whether your intentions for the following sprint may misalign with other areas of the organisation and potentially result in an impediment. They will be working in areas of the organisation that you may have little insight into and can inform you of potential dangers, pitfalls, and roadblocks down the line.
Discussing future sprints and providing stakeholders with insights into what the next few sprints look like, what may be achieved in that time period, and gaining buy-in as to whether that is good enough is incredibly important.
It enables the stakeholders to understand what the next few sprints look like and whether the most valuable work will be achieved within that time period. It also gives them an opportunity to comment and where possible, help to accelerate sprint goals and objectives.
So, if I had to distil a sprint review down to 3 key elements they would be:
- The conversation around what was being attempted in the sprint and what was actively achieved by the team. What is the difference, why does that difference exist and what could have been done differently with the benefit of hindsight? Bring this conversation to life and use it as an opportunity to demonstrate to stakeholders what impeded progress and actively ask for their help in removing those impediments to progress.
- Have a conversation about the product. Get feedback from product stakeholders and insights that actively help you work on the most valuable elements of the product at the most appropriate time. It isn’t a demo of the product. It is an opportunity to afford product stakeholders access to the product and to gain feedback from them. A demonstration is one-directional whereas interaction and engagement with your stakeholders is bi-directional.
- Have the governance discussion. Are we as a team going in the right direction? Are we producing valuable work that helps the organisation achieve its goals and objectives?
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you want to explore the opportunities coaching present to becoming a great scrum master, visit our on-demand Introduction to Coaching course page.