5 Things You Need to Stop Doing at the Sprint Review

A few weeks ago, one of the Scrum teams that I have been supporting informed me that they had not been doing Sprint Reviews because they had completed nothing worth demonstrating to the team or the stakeholders. I realized that this team did not fully understand the purpose of the Sprint Review, which is twofold: 1) Ensure alignment amongst the team regarding the progress made during the sprint, and 2) Showcase completed work products to the stakeholders and the team in order to gather feedback. There are many ways to lose sight of this key Scrum event, which is often seen as a superfluous “dog and pony show”. Let’s take a look at some of the other potential missteps that teams may take regarding the Sprint Review.

1. Hold meeting without Product Owner – Because many teams do not understand the goal of the Sprint Review, the Product Owner may often be considered an optional attendee. This is a big mistake that should be corrected immediately since the Product Owner is a key person that the team relies on for feedback and direction.
2. Show a PowerPoint presentation – Some teams feel that a polished presentation is what makes the team look good to stakeholders such as senior management. Hence, they invest significant time and effort to create a formal presentation that takes away valuable time in building the actual solution itself. The purpose of the demonstration is to share progress and gather feedback, which is not always achieved through a PowerPoint. A more valuable approach is to showcase the actual work artifacts that were created during the sprint, even if they are not refined.
3. Discuss only successes – Some sprints will be less successful than others for any number of reasons. In the interest of transparency, it is important to discuss both completed stories as well as items that encountered major issues. While some teams may disagree with my recommendation, I feel that sharing all of the information, both positives and negatives, helps to build trust amongst the team as well as sponsors.
4. Compare velocity against another team – Some organizations cannot resist the temptation to compare Scrum teams against each other. This is a dangerous practice that provides minimal value and adds significant risk of inducing unintended behavior. If you must compare team performance, use a percentage metric such as percent completed stories versus planned, which is much more valuable than velocity alone because velocity is most likely based on different scales across different teams.
5. Blame other teams for not completing all work – Teams that struggle to meet their commitments can often blame other external factors, which may or may not be reasonable. One suggestion is to focus on the work that your team has control over, and identify any critical external dependencies as early as possible so that you can create a mitigation or synchronization strategy to minimize such dependencies. Your team can only go as fast as the slowest dependency, so you have an incentive to eliminate this and help your team perform at their highest level

In conclusion, the Sprint Review can often be seen as yet another extra administrative meeting that your team does not value. Executed correctly, this event can become a critical forum for collaboration that could make the difference between a failed team and a high-performing one.