How’d your last sprint review go? If it was poorly attended, you’re not alone. Sparsely attended sprint reviews are a common problem with Scrum teams.
Having witnessed this with hundreds of teams, we can distill those situations into seven common problems. As I describe each problem, I’ll provide some advice to help you rectify the situation.
What seven problems lead to poorly attended sprint reviews?
1. Bad Time or Day
Sometimes reviews are poorly attended simply because the meeting is at a bad time or on a bad day. I worked with a team that ran one-week sprints, ending every Friday. Their reviews were Monday at 10 a.m., which ensured everyone had arrived in the office before the review. It also gave them time to make sure nothing had gone wrong over the weekend and the demo portion of the review would go well.
Unfortunately, this team’s reviews were not well attended even though the project was very important to stakeholders and stakeholders were otherwise engaged with the team.
After a handful of sparsely attended reviews, the Scrum Master was moved to investigate. He discovered that many of the stakeholders reported to the same director…who held weekly staff meetings every Monday at lunch.
This shouldn’t have been a problem as that director’s meeting was two hours after the sprint review ended. However, that director was tough to please and her direct reports often spent a couple of hours preparing for the weekly staff meetings. That often required time on Monday morning and so they skipped reviews they would have otherwise liked to attend.
If your reviews are not well attended, look into the simple solutions first such as whether their date and time are inconvenient for would-be attendees.
2. Boring
If stakeholders aren’t attending your sprint reviews, look in the mirror. Are your reviews boring? I’ve been to too many sprint reviews that made the Cats movie look exciting.
Some reviews become boring when teams demo everything they did during the sprint. This happens when a team demonstrates a bug fix that could only have been fixed one way. For example, a calculation that was always rounded down and should have instead rounded up or down as appropriate. Stakeholders don’t need to see that. Nothing has changed except the last digit in some number.
Rather than demonstrating such a feature, tell stakeholders the bug was fixed and move on.
Other times reviews become boring when discussions are allowed to drag on too long. Normally the Scrum Master will facilitate the review, but some product owners prefer to do it. No matter: the facilitator needs to be careful of letting discussions go on too long.
You certainly want to collect feedback during the meeting, but just be careful of going into too much depth on any one bit unless approximately three fourths of participants need to be involved in the discussion. If a small subset of meeting participants needs more discussion time on something, make note of it and announce that you’ll arrange follow up conversations or meetings afterwards.
Another way to prevent boring reviews is to better engage your stakeholders. Do this by handing them the keyboard or control of the app. If one stakeholder is experimenting with the product as you describe it, other stakeholders often perk up and pay a bit more attention.
3. Stakeholders Don’t See Why They Should Attend
You and I know what a sprint review is and why a stakeholder should make time for it. But do your stakeholders know? Often they don’t.
Unless you’ve explicitly communicated what happens during a review and what decisions will be made, your stakeholders may not see a need to attend.
As with nearly any meeting, I like to email an agenda to possible attendees in advance. In the agenda, I will list the product backlog items that will be discussed and key decisions I already know will be made during the review.
Equipped with that information, would-be participants can decide if they should attend. For example, I remember a review in which a team would be showing off new usability improvements they’d made in the sprint. An important stakeholder with no expertise in usability decided he wasn’t needed in the meeting.
And in this case, I contend that was the correct decision. If you publish a simple list of backlog items to be reviewed and decisions to be made, people can more intelligently decide whether to attend.
You’ll likely find that more opt to attend, but as with this director of analytics, there will be some who opt out of occasional reviews. That’s a win for the team as well because stakeholders learn that we respect their time.
4. The Reviews Take Too Long
I hate long meetings. I get seriously antsy if a meeting ever goes longer than 90 minutes. And I’m not alone.
The sprint review facilitator needs to keep the meeting moving at a brisk pace. In discussing boring meetings above, I already mentioned the need to avoid protracted discussions, moving them instead to be held outside the review.
A simple way to speed up reviews is to plan in advance who will do what. Agree which product backlog items will be demonstrated, in what order, and by whom.
I hate being in a review while the team decides which team member will demo each feature. I actually think it’s disrespectful to your stakeholders not to have figured that out in advance.
Additionally, you may want to add some entertainment to the review. Perhaps have the team enter the room as a smoke machine clouds the air, strobe lights flash, and stirring music plays.
OK, perhaps not. (Although I bet that would work.) But a smoke machine, strobe lights, and stirring music are gimmicks that P. T. Barnum might have used.
Barnum was the founder of the Barnum & Bailey Circus and was known as the preeminent showman of the 19th century. He is also remembered for saying, “Always leave them wanting more.”
That standard entertainment advice does apply to sprint reviews as well. Leave your meeting participants wanting more rather than wishing the meeting had been shorter. Do this by mentioning—rather than showing—trivial changes (as mentioned already). Also do it by showing perhaps 80% of a feature rather than every little detail of something new. If you’re asked, demo the remainder.
Always leave them wanting more. Good for showbiz, good for a sprint review.
5. Feedback Isn’t Solicited or Acted On When Given
Sprint reviews are intended to be two-directional. They’re conversations, not presentations. Not all teams understand the difference, and I’ve participated in sprint reviews in which stakeholders were not asked to share their opinions.
If I were invited to a meeting every couple of weeks and asked to sit through a presentation without an opportunity to share my thoughts, I’d stop going—just like your stakeholders have if you’re not asking their opinion.
Perhaps worse, though, is asking stakeholders for their opinions and then not acting on those opinions. I’m not saying a team must act on every stakeholder suggestion. Each suggestion should, however, at least be considered even if only briefly in some cases.
The solution here is two-fold:
- First, start asking stakeholders what they think as you demo each backlog item.
- Second, if asking isn’t generating responses, try asking more specific questions or asking specific individuals. Start with one of the more senior stakeholders and ask about a specific part of what was demonstrated. Or ask if a certain type of user would prefer something different.
Often once you get feedback started, others will add to it.
After that, be sure you consider what you’ve heard. Ideally incorporate some of it fairly soon so that stakeholders see their feedback matters. Be sure to point out the change in the next review and remind everyone it came as a result of feedback.
6. There Isn’t Enough Visible Progress
The sixth reason people may not be attending your sprint reviews is quite a bit different from those listed already. It’s that you don’t have much to show and so people don’t think it’s worth their time.
This might happen to a team running short, one-week sprints. Many products or systems are pretty complicated and it takes time to get things done. A team might be finishing user stories or other product backlog items in a week. But with a one-week sprint, it’s likely the items are pretty small.
Perhaps too small to really impress stakeholders.
Have you ever had a friend whom you saw regularly lose weight—but very slowly? Maybe they lost 20 pounds over a year. Good for them. But the weight loss might not have been noticeable at that rate if you saw the person weekly or daily.
It’s the same with short sprints, especially with a more complex product or system.
If you think this is why stakeholders aren’t attending, the first thing to do is ask them. If they confirm it as a reason, consider going to longer sprints. Alternatively, consider doing a sprint review every other sprint.
I know that breaks with Scrum canon. But a team running one-week sprints and doing a review every two weeks is still doing review twice as often as a team running a four-week sprint. And I can think of plenty of reasons why a team might want to continue its one-week sprints rather than sprint for two weeks.
7. Stakeholders Are Too Busy to Attend
Your stakeholders are busy. I know that because the last time I met someone who wasn’t busy was in 1993. But a project’s stakeholders are often very busy. They have their regular responsibilities and then a product needs to be developed and they’re assigned additional responsibilities.
And so they may opt to skip sprint reviews because they’re too busy. What they fail to understand is that a little time invested into each review is likely to save time down the road by avoiding problems and correcting potential misunderstandings.
If your stakeholders aren’t attending because they’re too busy, you have two options:
- Explain the value of sprint reviews.
- Get different stakeholders.
You’ve probably tried explaining the value of reviews already. And if it didn’t work then, it probably won’t work now—unless you can cite examples of misunderstandings or problems that would have been avoided if they’d attended reviews regularly.
And I might have made you laugh at the prospect of getting different stakeholders. But I sincerely meant that as an option.
I often see projects where the stakeholders are very, very important people in the organization. They legitimately don’t have time to participate in reviews or perform any other responsibilities a team may expect of its stakeholders.
In these situations, the solution is to get those would-be stakeholders to realize they are too busy and to delegate the stakeholder role to someone more available.
When you bring this up to a stakeholder, avoid sounding like you are accusing them of not doing their job well. Instead come across as sympathetic to (and appreciative of!) their effort. Discuss the possibility of them sending a representative instead of participating in the project personally.
I’ve had this conversation with many stakeholders who were obviously relieved by the suggestion that they delegate the responsibility. Deep down, they must have known that was the right thing to do.
Additionally, or perhaps alternatively, you can offer to record the sprint review and send them the recording. With many teams doing sprint reviews online these days, it is much easier to record a review than when reviews were entirely in person. If this is the route you take, make sure you set up a way to get feedback from the stakeholders not present at the time of the review.
Lack of Participation Is a Serious Problem
Stakeholders not participating in sprint reviews is a serious problem. It leads to misunderstandings being caught later in the process, sometimes so late that deadlines shift.
A lack of participation also sends a message to the team that the product they’re building is not very important. That is almost certainly not the case: there are less apocalyptic reasons for the empty seats, as the problems outlined here show.
The techniques outlined in this article should help you overcome the most common reasons people aren’t attending your sprint reviews.
What Do You Think?
Are your sprint reviews sometimes poorly attended? What was the reason? Were you able to correct the problem? Did one of the techniques described here help? Or if you tried something else, what was it? Please share your thoughts in the comments section below.
