Sprint Review Killers
13 ways to improve sprint review attendance and feedback
Jen, the team’s product owner, felt a sense of unease as the clock on her laptop turned to 11:02. The only people in the Zoom room were her team, who were quietly waiting for Jen to kick-off the meeting. The empty room wasn’t a shock to Jen though, this wasn’t the first time that nobody showed up to their Sprint Review. The empty room was confusing to her, all the agile books said that the Sprint Review should be attended by stakeholders which includes management, customers and developers from other projects. WHERE WERE THESE SO CALLED STAKEHOLDERS? The lack of attendance really irked her and the team. They worked hard on the latest feature, and it felt like their absence was an indicator that their product wasn’t important to the business.
Sound familiar? In this newsletter I want to talk about a very common struggle I see: Little to no attendance at the Sprint Review.
What is a Sprint Review?
The Sprint Review is a ceremony within Scrum. In that ceremony the Scrum Team (Development Team, Scrum Master, and Product Owner) present the work completed in the Sprint. The primary goal of the Sprint Review is to demonstrate the increment of work done and to gather feedback from stakeholders, including the product owner, customers, and any other relevant parties.
13 issues that kill Sprint Reviews
The attendance of your Sprint Review, or rather… the lack of, is a problem that can quickly demotivate a team and de-energize the Scrum ceremony. Here are common issues I’ve encountered over the years:
Stakeholder unavailability
Stakeholder role in the meeting is not understood
Lack of meeting consistency
Demo is too technical
Demo of partially completed work
Demo with no time for feedback
No demo due to lack of UI
Context of the work is missing
Unpreparedness, awkward pauses or gaps
Progress and achievements aren’t celebrated
Focus on documentation over working software
Overly long and unfocused feedback discussions
Team resistance to feedback
Addressing the Sprint Review killers
As you can see the list of Sprint Review killers is long and… complicated, because:
Sprint Reviews are an art and science
The Sprint Review is a balance of meeting facilitation basics, professional and charismatic demonstration, and bi-directional conversation. Without these fundamentals things can quickly fall apart for a team.
Let’s dive into the killer list so I can offer some insight and ways to address the problems.
Stakeholder unavailability
Stakeholders are unavailable according to their calendar.
It’s a pain, but the meeting owner MUST take the time to talk with stakeholders to work out a time they can attend. Their calendars don’t often paint an accurate picture of the availability, so it requires additional conversation and moving a few things around.
Stakeholder role in the meeting is not understood
Given the meeting agenda, dynamics, and ownership the stakeholder doesn’t understand their place/role in the meeting.
Make stakeholder role expectations explicit in the meeting invite; something along the lines of: “Your attendance as a stakeholder is required so that we can get your feedback on our work before we commit to the work in our next Sprint”.
Lack of meeting consistency
Your team is canceling the meeting quite often.
Ensure that your Sprint Reviews are consistently happening, the consistency is easier for stakeholders to depend on. When the meeting is undependable, their attendance becomes undependable.
Demo is too technical
Developers tend to get too far into the technical weeds, losing the majority of the audience.
Ensure that the stakeholder value is being presented. Have the team practice, look for those “look squirrel” and deep dive tendencies and then squash them.
Demo of partially completed work
The work is fragmented and/or incomplete which can confuse stakeholders.
It’s tempting to show what you’ve got partially done, but if the work isn’t a thin vertical slice through your stack you’re going to lose your stakeholder on the context and applicability in the big picture. The fix… at a minimum, demo completed work.
Demo with no time for feedback
The demo part of your Sprint Review is too long and doesn’t allow time for feedback.
Make sure your demo is practiced for timing, brief and to the point, and demo with a sense of haste. This will help ensure you are leaving room for feedback.
No demo due to lack of UI
The team doesn’t have a UI, or UI work to demo, so they think Sprint Reviews aren’t applicable.
Remember that the team is demonstrating completed work, it doesn’t to have a UI. They might be demonstrating header and body of an API request and/or response; or running a command from the cmd line and looking at the response. That’s okay!
Context of the work is missing
A stakeholder might be confused to the context of what you are demoing and lose interest.
It’s always a good idea to start the Sprint Review with context of the work in the big picture; perhaps in a roadmap, or where it fits in an epic, or where it fits in with a release schedule. Don’t be afraid to provide context while demoing as well.
Unpreparedness, awkward pauses or gaps
The team starts late, or forces stakeholders to awkwardly wait while fumbling through technical detail or setup, or the handoffs are uncoordinated or simply lack flow.
Practice! At least one test run will go a long way in making the team talk through content, handoffs and overall time of the Sprint Review.
Progress and achievements aren’t celebrated
The Sprint Review feels like a death march, lacks energy and appreciation.
The Sprint Review should also be a celebration of the work achievements. Stakeholders should be reminded of this, you can do so with commentary in the presentation slides, and asking for a round of applause at the end of the meeting.
Focus on documentation over working software
The team is demoing documentation.
Stakeholders don’t need a meeting to watch you read docs. Ensure the focus is on demoing working software.
Overly long and unfocused feedback discussions
Feedback sessions get into the weeds and turn more towards technical design and/or planning.
The entire audience has no interest in hearing feedback being resolved during the meeting. The Sprint Review facilitator must carefully guide these conversations and interject if they get to far into the weeds, suggesting that there be a follow up meeting to hash out further details.
Team is resistant to feedback
The team hears feedback but is consistently resistant to it.
It’s important to remember that the stakeholder is your customer. If the team is resistant to their feedback, the stakeholders will be disenchanted and might stop attending. It’s important to hear and repeat the feedback, and if there is a disagreement have it taken offline for further discussion and better alignment.
In Summary
Addressing the pervasive issue of low attendance at Sprint Reviews is crucial for the success and morale of our teams. As I’ve written, there are a lot of things that can impact the perception, attendance and ultimately success of your Sprint Review. Spending time thinking about the audience perspective and tweaking your practice and techniques will go a long way in increasing your Sprint Review attendance. Establishing a solid Sprint Review is an adventure; don’t forget to solicit feedback, iterate and experiment to improve over time!
Have you experienced other killers? Share it in the comments!