5 Things You Should Never Say (or Do) During Sprint Reviews

The Sprint Review seems like one of the simplest Scrum events to execute, yet many teams tend to miss this key opportunity to inspect the progress of work. From my experience working with a variety of teams with different levels of experience, most teams see the Sprint Review as a “demo”, which is partially correct, but not entirely the intent of this event. In order to reap the benefits of the Sprint Review, teams should focus on assessing the work that has been completed, sharing progress, challenges, and issues, and most importantly, get feedback from the stakeholders.

There are many ways to lose focus in a Sprint Review, and I would like to share a few that I have personally witnessed. Take a look below and see if you have experienced these also, then think about whether it makes sense to avoid these traps.

During your Sprint Review, you should NEVER…

1. Demonstrate incomplete work – There are different opinions regarding whether a team should showcase only completed work or also discuss incomplete work in order to demonstrate a concerted effort had been made by the team. My thinking is that showing incomplete work, while consistent with the value of transparency, can add more risk than benefit to the team due to potential misunderstanding of the current state of the project. My recommendation is to focus on the positives – the completed functionality – then discuss any issues or roadblocks that prevented other work from being completed as planned.
2. Say “We planned too much/too little work” – Since a Scrum team creates a forecast of what they believe can be completed during a Sprint, the plan should not be considered a “forecast” or a “prediction”. The team should not dwell on whether too much (or too little) work was planned, but rather, focus on the value delivered. A good question to ask: “Did the value that the team delivered to meet the expectations of the Product Owner?”.
3. Say “We need to complete more points next sprint” – To augment item #2 above, the goal of the Scrum team is to deliver value, not points. There is not necessarily a direct relationship between the volume of points (story points) that a team produces to the actual value delivered to the customer/end-user. Asking for or pushing for more points is not the appropriate way to focus the team, since this can lead to point inflation which adds no benefit to anyone. The team should try to focus on the best way to deliver more value through improvements in efficiency, automation, and other innovation.
4. Say “We have nothing to show” – In the unlikely event that the team is unable to complete any tangible functionality within a sprint, which may happen, the team should try to focus the Sprint Review on progress made and obstacles that were encountered. This may feel like a Retrospective discussion, but that’s okay; if the team is in this situation, then it is important to have a dialog around what happened and what needs to be changed to improve the outcomes for the next sprint.
5. Present slides instead of inspecting work items – The Sprint Review is designed for teams to demonstrate a working product instead of talking about the product and what it could have been. Hence, avoid the temptation of showing PowerPoint slides and talking only about metrics; while important, metrics are not what the customers pay for, and they would benefit from seeing the actual product, even if it is not 100% complete. In the event that functionality requires significant time to execute (i.e. a process that must run for several minutes or hours to complete), it is okay to show a screenshot of the inputs and outputs of that process.

To close out this article, the key takeaway is that a Sprint Review is designed to provide another opportunity to inspect and adapt; the customer/stakeholder will appreciate the transparency and visibility into how things are progressing, even if the outcome is not exactly ideal. By demonstrating progress and seeking feedback consistently, your team will have a good chance to build trust and rapport and also improve alignment with stakeholder needs, which will ultimately help you build the best possible product/solution.

Eugene Lai