Why Do Sprint Reviews Bore People to Death?

Five common reasons Scrum Teams hate Sprint?Review.

“Can we cancel the Sprint Review for today?” Developers asked the Scrum Master. Why would they ask such a question?

The Sprint Review is a great moment to have a meaningful exchange with stakeholders, where the Scrum Team has an opportunity to inspect and adapt. That’s what it should be like in theory, but unfortunately, it’s not a reality for most teams.

I’ve faced so many scenarios where Scrum Teams would do anything to skip the Sprint Review. Some excuses were:

• We must finish the Sprint
• We don’t have anything to show
• No stakeholders attend, so we shouldn’t go as well. Let’s cancel this week, and then we will do it next time

These are symptoms of anti-patterns. I came across some reasons that keep the Scrum Teams from getting the expected benefits during the Sprint Review.

What’s the Sprint?Review?

Before we discuss what we should not do during the Sprint Review, let’s understand what this event is.

Let’s look into the Scrum Guide. I put in bold the essential aspects.

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.— The Scrum Guide

The Sprint Review is vital to evaluate the Increment. Stakeholders and the Scrum Team have the chance to inspect and adapt. Collaboration is a crucial aspect of having a successful event. That’s why an informal format will work better.

#1 - Status Report

Product Manager: “Let me open Jira, then you can tell me where we are.” That’s the moment the Scrum Team goes back to the traditional development approach.

Individuals and interactions over processes and tools — Agile Manifesto

Sometimes Product Managers behave as classic Project Managers. In this scenario, the Product Manager may run the Sprint Review as a status report meeting, which blocks the team from achieving the benefits of the Sprint Review.

What does this meeting look like?

• The Product Manager opens Jira (or another tool) and asks the team, “Where do we stand?”
• Developers explain the status of each item inside the Sprint.
• The Product Manager evaluates some items, approving or rejecting them.

If the Status Report takes over the Sprint Review, sometimes not even Stakeholders attend the event.

Once the Sprint Review becomes a Status Report meeting:

• Developers will insist on canceling the event.
• The focus is on the tasks delivered instead of the business value.
• Inspection and adaption will not take part in the meeting.
• Stakeholders will be blind because transparency is not happening.
• Low collaboration between developers and stakeholders.

#2 - No Stakeholders

“Sorry I can’t attend the Sprint Review today,” said the stakeholders. Once stakeholders decide to skip the Sprint Review, the message is clear, “I have more important things to do.”

A Sprint Review without Stakeholders is meaningless. Without them, the Scrum Team has no chance of achieving the Sprint Review goals.

Why would stakeholders skip the Sprint Review? Either the Sprint doesn’t contribute to their needs, or they are “too busy” for the team. This is a situation that the Scrum Master should handle. It can demotivate the Scrum Team because the team wants feedback on their work. Otherwise, how do we know we are in the right direction?

If Stakeholders are too busy for the team, problems with expectations are inevitable.

#3 - Product Managers run the?show

Product Manager: “Hi, everyone. How are you? Today I have many features to present to you!”. That’s the moment when developers lose their motivation.

Scrum Teams have no hierarchy. Some Product Managers behave as if they are on the team’s top. This is a huge mistake; the Product Manager is part of the team.

The Sprint Review is a moment to collaborate with stakeholders to identify opportunities and corrections needed to maximize value. It is not a moment for the Product Manager to shine, but for the whole team. They should present the Increment, which they have put much effort into. Once the Product Manager decides to run the show:

• Stakeholders may see the Product Manager as the manager of developers
• The Product Manager answers all questions, reducing the chance of collaboration between Stakeholders and developers
• The developers are no more than attendants in the meeting

I am not saying Product Managers should not speak during the Sprint Review. I believe Product Managers could set the stage. For example, the Product Manager could highlight the essential parts and their importance, then hand them over to developers, which run the presentation. Then developers run the show.

#4 - Presentation instead of working?software

Developer: “Let me open the presentation we prepared for our meeting. I will guide you through our progress.” That’s when stakeholders decided to have a nap.

The Sprint Review should foster collaboration. Therefore, the Increment is vital, which is working software instead of a presentation. But why do some Scrum Teams choose this approach? The reasons can vary a lot; some possibilities are:

• Technical outcome: the Increment is an API that developers don’t know how to present to the Stakeholders
• Unfinished work: developers haven’t finished the work but decided to present what it should be once it is finished.
• Complexity: the Increment is complex, so developers couldn’t find how to present it to Stakeholders. The presentation seemed to be a more comfortable alternative.

Any of that is an excuse to skip showing real working software. Developers should find alternatives to present the Increment. The Product Manager fails to prioritize relevant Product Backlog Items if no business value is generated. The Sprint Review is a moment to evaluate if the Scrum Team is in the right direction.

A presentation is only a promise of something. It’s not the real working software. Therefore, it sets the team apart from the Sprint Review’s goals.

#5 - Low engagement

Stakeholders are in the Sprint Review only physically, but they don’t collaborate. This is a sign of wrong priorities or the wrong audience.

Some Sprint Reviews have a relevant audience, yet, no collaboration takes place. Why does it happen? If the Increment is not what the audience needs, they will not be interested in collaborating. Some common mistakes lead to this situation:

• Features instead of value: if the Product Manager decides to focus on building new features. Stakeholders may enjoy it for some time, but once they realize the outcome is not optimal, they will disengage and reduce collaboration.
• Minor improvements: once the Product Manager mutates into an order-taker, everything becomes a priority. The Increment of the Sprint is a set of small meaningless changes that nobody cares about.
• Stakeholder has no voice: once stakeholders feel the Product Manager does not hear them. They get demotivated because the outcome of Sprint does not match their expectations.

Endnote

The Sprint Review is not optional. However, the Scrum Team must pay close attention to get the benefits from this event. A terrific Sprint Review has the following characteristics:

• The Product Manager sets the stage, and developers run the show
• Developers present real working software
• The Stakeholders collaborate with the Scrum Team to identify opportunities to optimize the business value
• Everyone leaves the room feeling we are all going in the right direction