Sprint Review — 10 common pitfalls to avoid.

Before we go ahead and talk about some of the common anti patterns that I see or have seen in my career, let me explain what is a Sprint Review. The Scrum Guide describes the Sprint Review as — The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Now, if we read & understand the text from the scrum guide, we get to know that like all other Scrum events, the Sprint Review too is an even to practice Empirical process control. The sprint review is an event where Empiricism visibly and vividly comes to life, or at least should. However, there are many pitfalls that numerous teams do not avoid, and hence they fail to utilize the sprint review for the purpose it is intended for. Let’s take a look at some of the most common anti patterns that I have seen in the real world:

1. Not enough stakeholders to collect feedback from — I have seen this multiple times, that stakeholders refuse the sprint review invite stating conflicts or any other reason. The stakeholders, users must make time on their calendars to attend reviews, inspect the increment & provide their feedback.
2. Non interested or non attentive stakeholders — I have also seen numerous times, the users or stakeholders not pay their complete attention when the scrum team is presenting the increment. The event concludes without any questions, feedback.
3. Not relevant audience in reviews — Another common anti-pattern is that the list of invited stakeholders, users never change over time. While continuity of stakeholders in necessary to have that engagement with them, but if and when the increments change which warrants new or additional attendees, the invitee list should be amended.
4. Product Owner behaving as a stakeholder — I have also sometimes seen the product owner treating himself as a member of the users and not the scrum team. The result : Product Owner isn’t fully aware if the increment achieves the Definition of Done, and accepts or rejects the stories at the sprint review.
5. Dev Team gamifying the increment — Many a times, when adequate psychological safety doesn’t exist in the teams, they try to portray a picture that is merrier than the reality. The try to gamify the increment to show it as a fully working increment (meeting the DoD), when it was not. This impacts Transparency, and subsequently the group’s ability to Inspect & Adapt.
6. The infamous PowerPoint reviews — Now, how many time shave we seen this? The sprint review is an opportunity to inspect the working software, and that cannot be done over a PowerPoint, period. Anything that limits or impacts transparency of the increment should be avoided.
7. Not leaving enough time for questions & feedback — Though Demo of the working software is necessary and indispensable, but the team should keep the purpose or intent of the demo in their minds. The intent of demoing the increment is to inspect it and collect feedback to help adapt the future backlog.
8. Product Owner and team not documenting feedback — I have also seen multiple times that the stakeholders did provide feedback, but nothing was taken seriously or actually documented by the PO and team, resulting in no adaptation done.
9. Not celebrating success — Tell a compelling story of the sprint achievements. This helps build empathy into your sprint stakeholders and helps them understand the challenges of the team. The celebration also motivates the team to continue their good work.
10. And lastly, the most important and common one — Understand the meaning of increment. An increment is the current sprint’s work + previous sprints work, not only the current sprint work. How many times have we seen the team inspecting only the current sprint work? Remember to inspect the complete latest increment with your stakeholders, because only then you would be able to make the right adjustments needed.