In this piece, we’re taking a deep dive into the sprint review so that you can learn how to improve the sprint reviews in your teams. If you want to learn about the other 4 ceremonies in the Scrum project management system, be sure to check out our blog post on the topic.
Table of Contents
- What is the Purpose of the Sprint Review?
- What Sprints Review Are NOT
- How to Conduct Better Sprint Reviews
- Conclusion
What is the Purpose of the Sprint Review?
Although the sprint review embodies all 3 Pillars of Scrum—transparency, inspection, and adaptation—it emphasizes the last two: inspection and adaptation. According to the official Scrum Guide, the purpose of a sprint review is: “to inspect the outcome of the sprint and determine future adaptations.”
In other words, you take stock of what was accomplished in the last sprint and use that to update your plans for future sprints.
What Sprint Reviews Are NOT
Let’s take a moment to dispel two common misconceptions about sprint reviews.
A Sprint Review is NOT Just a Demo
A key part of a sprint review is that the team presents what they achieved in the last sprint. This information sharing allows all the relevant stakeholders to be informed about changes to the product. It also helps boost team morale, which we’ll talk about later.
But, a sprint review should not just be a string of “show and tells.” Each demo should serve as the launch point for conversation about the new functionality. There should be praise but also questions and feedback about the potentially shippable product increment. Feedback from stakeholders from the business side helps to ensure that product increments are adding the greatest amount of business value.
The Product Owner (who is typically the Product Manager) should take in all this feedback and use it to guide the direction of the product. After the sprint review, the Product Owner should have a lot of information to process. The end result should be a Product Backlog that incorporates all the learnings discovered during the sprint and the sprint review.
A Sprint Review is NOT the Same Thing as a Sprint Retrospective
This is a super common mistake, and it’s understandable. Both occur after the sprint and the terms themselves are very similar. What’s the difference between a “review” and “retrospective”?
But the sprint review and sprint retrospective are completely separate ceremonies. The easiest way to distinguish them is the following: The sprint review focuses on the product while the sprint retrospective focuses on the process.
In a sprint review meeting, every relevant stakeholder is invited, even those who aren’t part of the Scrum team. This is because the focus is on the product. But in a sprint retrospective, only the Scrum team is there, because it’s a meeting for the Scrum team about the Scrum team. The goal of the review is to improve the product in future sprints while the goal of the retrospective is to improve how the team performs in future sprints.
How to Conduct Better Sprint Reviews
Begin by Framing the Sprint Review
At the beginning of every sprint review, the Product Owner should remind everyone of the sprint goals and give the necessary context to understand the stakes of the sprint. This helps everyone understand what was intended for the sprint, why those intentions were set in the first place, and how the outcomes of the sprint line up with what was planned.
The sprint backlog alone can’t answer these questions. That’s why teams rely upon tools like the Project Delivery Tracker from LinearB, which can give them more visibility into the sprint. LinearB’s Planning Accuracy metric, for instance, tells you at a glance precisely how much of the planned work you actually completed during the sprint.
Celebrate the Wins
The best teams ensure that sprint reviews are celebratory. (There’s a reason many teams hold them on Friday afternoons, right around happy hour.) People worked hard to create new functionality, and that hard work deserves to be recognized. By celebrating one another’s achievements, you bring a team closer together and motivate people for the next sprint.
Motivating a team is a key part of people management, which is essential to software engineering. On the Dev Interrupted Podcast, Hyrum Wright, Senior Staff Engineer at Google, explained how he believes that software engineering is not a technical problem but a people problem.
If your team comes out of a sprint review not feeling excited for the next sprint, this indicates something is wrong. A common cause is that teams feel like they’ve let the company down when they don’t meet their sprint goals.
LinearB can help you prevent this disappointment. Our Investment Profile tells you exactly where the development team spent their time during the sprint. This enables you to identify and easily communicate what the team did accomplish. For example, they may have had to respond to urgent bug fixes or pay down technical debt that prevented them from shipping new functionality. But that work was valuable and it deserves to be celebrated even if it wasn’t planned for.
Take the Time to Update the Product Backlog
Once the sprint review is over, the Product Owner should process all the feedback, extracting insights and action items. All this new information should make its way into the Product Backlog. The Product Owner should add new user stories and issues as well as update the data on existing Product Backlog items like their business value and story points. This ensures that the next sprint planning session is more constructive and that the upcoming sprint will be more fruitful.
LinearB can make the process of updating the backlog not only faster but also more accurate. The Pulse Dashboard shows you how much work went into each issue, so that you can see whether you are systemically misestimating how much work an issue/user story requires. The planning accuracy metric can also help reveal if there’s a persistent mismatch between work anticipated and work required. By having a better grasp of achievable delivery dates, you can plan better and improve alignment across the entire company.
Conclusion
Just because the development work has finished, a sprint isn’t over. You need to also bring energy and intentionality to the sprint review.
It will help to replenish enthusiasm among the team heading into the next sprint. A high-quality sprint review also helps to inform everyone about how the product has changed and give them the opportunity to share feedback and ensure that the product is heading in the right direction. This means that the hard work done during future sprints will prove to be even more valuable.
With LinearB you can not only have more productive sprint reviews but also improve each stage of your development process. Get in touch with us to set up a demo and learn about all the ways you can start shipping better code faster with LinearB.
