Why most Sprint Reviews are boring
Five common reasons Scrum Teams hate Sprint Review
Five common reasons Scrum Teams hate Sprint Review
“Can we cancel the Sprint Review for today?” The Development Team asked.
But 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 at least, 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.
Let’s cancel this week, and then we do it next time.
No stakeholders attend, so we shouldn’t go as well.
These are symptoms of anti-patterns. I came across some reasons which hold the Scrum Teams back 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.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
The Sprint Review is vital to evaluate the Increment. The stakeholders and the Scrum Team have the chance of inspecting and adapting. Collaboration is a crucial aspect to have a successful event. Also, it’s informal. So the Development Team should present working software instead of a PowerPoint.
Status Report
Product Owner: “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 Owners behave as Project Managers. In this scenario, the Product Owner may run the Sprint Review as a status report meeting, which blocks the team from achieving the benefits of the Sprint Review.
How does this meeting look like?
The Product Owner opens Jira (or another tool) and asks the team, “Where do we stand?”
The Development Team explains the status of each item inside the Sprint.
The Product Owner 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:
The Development Team 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 the Development Team and stakeholders.
No Stakeholders
“Sorry I can’t attend to 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.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Why would the Stakeholders skip the Sprint Review? Either the Product is not interesting for them, or they are “too busy” for the team. This is a situation which the Scrum Master should handle. It can demotivate the Scrum Team quite a lot, 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.
Business people and developers must work
together daily throughout the project.
Product Owners runs the show
Product Owner: “Hi everyone. How are you? Today I have a lot of features to present to you!”. That’s the moment when the Development Team loses its motivation.
Some Product Owners behave as if they are on the top of the team. Which is a huge mistake, the Product Owner is part of the team. Scrum Teams have no hierarchy.
The Sprint Review is a moment to collaborate with the stakeholders to identify opportunities and corrections needed to maximize the business value. It is not a moment for the Product Owner to shine, but for the Development Team. They should present the Increment, which they have put a lot of effort into it. Once the Product Owner decides to run the show:
Stakeholders may see the Product Owner as the manager of the Development Team.
The Product Owner 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 Owners should not speak during the Sprint Review. I believe Product Owners could prepare the stage. Then the Development Team runs the show. For example, the Product Owner could highlight the essential parts and the importance of that, then hand over to the Development Team, which runs the presentation.
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.
Working software is the primary measure of progress. — Agile Manifesto
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, which the Development Team doesn’t know how to present to the Stakeholders.
Unfinished work: the Development Team hasn’t finished the work, but decided to present what is supposed to be once it is finished.
Complexity: the Increment is complex, so the Development Team couldn’t find how to present it to the Stakeholders. The presentation seemed to be a more comfortable alternative.
Any of that is an excuse to skip showing real working software. The Development Team should find alternatives to present the Increment. If no business value would be generated, then the Product Owner failed to prioritize relevant Product Backlog Items, the Sprint Review is a moment also 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.
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, then they will not be interested in collaborating. Some common mistakes lead to this situation:
Features instead of value: if the Product Owner 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.
Small improvements: once the Product Owner mutates into an order-taker, everything becomes a priority. The Increment of the Sprint is no more than a set of small meaningless changes that nobody cares about.
Stakeholder has no voice: once stakeholders feel the Product Owner does not hear them. They get unmotivated because the outcome of the Sprint does not match their expectations.
Wrap-up
The Sprint Review is not optional. However, the Scrum Team must pay very close attention to get the benefits from this event. A terrific Sprint Review has the following characteristics:
The Product Owner sets the stage, and the Development Team runs the show.
The Development Team presents real working software.
The Stakeholders collaborate with the Scrum Team to identify opportunities to optimize the business value.
Everyone leaves the room with the feeling we are all going in the right direction.
Do you want to write for Serious Scrum or seriously discuss Scrum?