In the Scrum framework, sprint reviews play a crucial role in the success of product development work. These reviews are an opportunity for the developers, stakeholders, and customers to come together and evaluate the progress made during a sprint. Let’s go deep into the purpose of a sprint review in Scrum, looking at their importance in promoting transparency and continuous improvement. Hopefully by the end you can get a good understanding of the purpose of sprint reviews.
To really get the purpose of sprint reviews, it’s essential to understand the principles and values behind Scrum and the Agile Manifesto. Scrum, a popular Agile framework, emphasizes collaboration, adaptability, and customer-centricity. The Agile Manifesto, on the other hand, puts individuals and interactions, working software, customer collaboration, and responding to change as the priorities.
There is some common overlap you can see here. Customer feedback and delivering value to customers is a major theme in both systems. So is transparency and adaptability. And that’s where sprint reviews come in. Sprint reviews are a mechanism for enabling transparency, inspection and adaption. Which are the three pillars of the Scrum framework.
The primary objectives of sprint reviews revolve around gathering feedback, and validating increments. In Scrum, a team is meant to produce at least one working product increment, each sprint. And at the end of the sprint, the team shows all their work in a Sprint Review event.
The Scrum Guide itself says specifically:
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
The Scrum Guide, 2022
By showcasing the work completed during the sprint, teams can get feedback from stakeholders and customers. These insights help with improvement and ensure that the product aligns with the evolving needs of the users. Without feedback (from a real working product, not some screenshots or made-up video footage), the Scrum team will be guessing about what to build.
The team can take that feedback, and use it to inform not only their work for the next sprint, but the overall product backlog and product roadmap.
So we can see that sprint reviews uphold the principles of transparency, inspection, and adaptation. These are the three pillars of Scrum and Empiricism. And they enable teams to continuously refine their approach and build high-quality software.
Sprint reviews offer numerous benefits that contribute to the overall success of Agile software development projects.
Firstly, they promote team collaboration via a platform for discussion and knowledge sharing. By involving stakeholders and customers in the review process, the team gains an understanding of their expectations and priorities. This, in turn, leads to higher customer satisfaction and a better alignment of the final product with their needs.
The last thing you want is developers stuck inside a “feature factory”. Just spitting out stories and features, without ever talking directly with stakeholders. This lowers morale and reduces outcomes.
A sprint review is a really good opportunity to bring all these people together at a table. And get them talking about what really matters: the value of the product they are building.
Sprint reviews also enable teams to identify and address issues early on, resulting in improved product quality and reduced rework. If stakeholders or customers aren’t happy with a product feature and don’t believe it meets their quality expectations, the best time to find that out is straight away. Not three months later after a big product launch!
To conduct successful sprint reviews, certain practices can really enhance their effectiveness.
Involving stakeholders throughout the review process is crucial, as their input and perspectives contribute to a proper evaluation. The last thing you want to do is to do a sprint review and the only person there to see the product is the Product Owner! This is a total waste of time, since the Product Owner is already part of the Scrum team. And should be continually inspecting the product.
So make sure to invite a wide range of stakeholders. These could be project sponsors, end users (or their representatives), or specialist stakeholders. These vary from domain to domain but could be people like change managers, release coordinators, marketing executives, and so on.
Make sure the team is showing actual finished work. Don’t be tricky and hide things! Talk transparently about issues you faced. Be honest. If the team completed nothing, then show nothing, and talk about what happened and why and what the team are planning to do about it. We don’t want Watermelon Projects! (Green on the outside, red on the inside – you know what I mean!).
Try and avoid powerpoint if at all possible. Show actual products, i.e. actual working software! This is a review, not a trade show. No screenshots or marketing videos. Show the real working thing. This is true transparency, which is Scrum is all about.
Make sure to have real multi-way conversations about the product. Remember, no presentations! This is meant to be a discussion, not a sales pitch or demo. (I always try and avoid using the words “demo” or “showcase” for Sprint Review, since they encourage this kind of opaque one-way roadshow style).
Get people talking honestly and transparently. Invite questions and feedback. Discuss concerns, risks and pain points.
The Sprint Review is an ideal time to inspect and update the Product Backlog. Most of the feedback items from Stakeholders could become backlog items. So get them in there! Even if at this stage they just outlines, talking points or skeletons.
It’s ok to do this just after the Sprint Review. But don’t wait too long, or the information and discussion won’t be as fresh in your mind.
There are plenty of case studies and examples of Scrum and its events. Many of them are listed here, on the Applied Frameworks site.
One thorough one I found was here, on the PDXScholar website. It is an honours thesis from Portland State University. It goes into detail about how Scrum was used (including Sprint Reviews). You might it useful to help get an understanding of the purpose of a Sprint Review in Scrum.
For further insights and perspectives on sprint reviews, consider exploring the following resources:
These sources might help you to get a deeper understanding of sprint reviews and their role in Agile software development.
So sprint reviews are not just a checkbox to mark at the end of a sprint. They are a really important mechanism for teams to inspect and adapt, ensuring that the product meets the evolving needs of the customers. By running effective sprint reviews, involving stakeholders, and focusing on customer value, teams can deliver software that delights users and creates value.
So make sure to do sprint reviews properly in Scrum. Use the transparency, inspection, and adaptation they offer to drive continuous improvement. And to deliver high-quality products that resonate with end-users.
Do you have different ideas on sprint reviews? Have you had much success with them? I’m very interested to hear your thoughts, so let me know in the comments section below.