Sprint reviews are a built-in way to engage stakeholders in a project every few weeks, at a minimum. The sprint review meeting is the time for teams to talk about the functionality they have created with the people who need and want that functionality.
As such, sprint reviews can be the most exciting meeting of every iteration. Too often, though, sprint reviews don't live up to their promise. Stakeholders don't attend, are bored, or sit passively waiting for the meeting to end.
Sprint reviews are a vital time for collaboration.
-
The Scrum Master, product owner, and developers need (and deserve) feedback on delivered features, and ideas about what to deliver next.
-
Stakeholders need (and deserve) to know how the product or service is progressing. They want to steer the project in the right direction.
I have seen the ineffective sprint reviews of hundreds of teams. I have also identified seven ways to help teams and stakeholders make sprint reviews interesting and engaging.
1. Choose the Right Day and Time
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. They scheduled their reviews for Monday at 10 a.m. to ensure everyone had arrived in the office before the review.
Few people came. The Scrum Master was puzzled because the stakeholders were otherwise very engaged with the team. The Scrum Master asked a few questions and soon discovered the problem. Many of the stakeholders reported to the same director, who held weekly staff meetings every Monday at lunch. That particular director was tough to please, so the direct reports often spent a couple of hours on Monday mornings preparing for the weekly staff meetings. That prep time prevented those key stakeholders from coming to sprint reviews.
If your reviews are not well attended, look into the simple solutions first, such as whether the date and time are inconvenient for would-be attendees.
2. Engage Stakeholders During the Review
If stakeholders aren’t attending your sprint reviews, look in the mirror. Maybe your reviews are simply too boring to effectively engage stakeholders.
Reviews can become boring when teams demo everything they did during the sprint. There is no need, for example, to demonstrate a bug fix that could only have been fixed one way. Just tell the stakeholders the bug was fixed and move on. Show the fix if they really want to see, but they probably won’t.
Reviews can also become boring when discussions are allowed to drag on too long. Whoever is facilitating the review (typically the Scrum Master) must be careful to keep discussions on topic and engaging.
Discussions are essential for collecting feedback during the meeting. Be careful, though, of going into too much depth unless approximately three-fourths of participants need to be involved.
If a small subset of meeting participants needs more discussion time on something, make note of it. Announce that you’ll arrange follow-up conversations or meetings afterwards. Then, move on.
Another way to prevent boring reviews is to directly involve 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. Get Stakeholder Buy-In on the Importance of Sprint Reviews
You and I know what a sprint review is and why a stakeholder should make time for it. But do those outside the Scrum team understand why sprint reviews and stakeholder engagement is important? Maybe not.
Unless you’ve explicitly communicated what happens during a review, how stakeholders will be involved, and what decisions will be made, stakeholders may not see a need to attend.
How do you get buy in from stakeholders about sprint reviews?
One way I do it is by including an agenda with the calendar invitation. In the agenda, I list the sprint goal and the product backlog items that will be discussed and key decisions I know need to 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. Simply publishing the sprint goal and user stories to be reviewed, along with the decisions to be made, helps people 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. Keep Reviews Short
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.
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. 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, some way to add a little fun, grab people’s attention, or break the ice. I'm not saying you have to find ways to make every review the "Greatest Show on Earth." But a little fanfare doesn’t hurt.
Speaking of the Greatest Show on Earth, take some advice commonly attributed to its co-founder P.T. Barnum: “Always leave them wanting more.”
Leave your meeting participants wanting more rather than wishing the meeting had been shorter. Do this by mentioning—rather than showing—trivial changes. 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. Solicit Feedback and Take It Seriously
Sprint reviews are intended to be two-directional. They’re conversations, not presentations. Not all teams understand the difference. I’ve participated in far too many 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 with no opportunity to share my thoughts, I’d stop going. So don't be surprised if your stakeholders stop showing up 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.
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. Review When Progress Is Visible
The sixth way to encourage stakeholders to come to sprint reviews is quite a bit different from those listed already. Sometimes the development team doesn't have much to show, 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 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. Or consider keeping your short sprints, but doing a sprint review every other sprint.
I know that breaks with Scrum canon. But think about the math. If a team is running one-week sprints and doing a review every two weeks, they are doing reviews twice as often as a team running a four-week sprint. I can think of plenty of reasons why a team might want to continue its one-week sprints rather than make them longer.
7. Find Solutions for Busy Stakeholders
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 individuals who are often very busy. They have their regular responsibilities and then they’re assigned new responsibilities for a product under development.
One way to justify the time invested in sprint reviews is to remind everyone about the time it saves later. Investing a small amount of time into each review can save time in the future. It can help to avoid issues and clear up any potential confusion early in the project.
For example, I worked in a call center systems project once. The developers and Scrum Master were not allowed to talk to the stakeholders at all, not even at a review. The theory was that the call center agents, who were all nurses, were far too busy. (That busyness was why they needed new software.)
But without being able to learn their needs first-hand, we were making some bad decisions.
Everything had to funnel through our product owner. That was not a scalable solution with over one hundred developers on the project.
The developers resorted to stalking the nurses in the lunch room. This was the only time they could meet; when a nurse was taking their break. The project was successful. However, it could have gone faster, had the programmers and Scrum Master been granted more access to stakeholders and decision-makers.
If your stakeholders aren’t attending because they’re too busy, you have two options (three if you count stalking them in the lunchroom):
- Sell them on the value of sprint reviews.
- Get different stakeholders.
You’ve probably tried explaining the value of reviews already. If it didn't work before, it likely won't work now, unless you can show examples of mix ups or problems that would have been avoided if reviews had been attended 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 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.
Agile Projects Need Engaged Stakeholders
Stakeholders not participating in sprint reviews is a serious problem. It leads to missteps being caught later in the process, sometimes so late that deadlines shift.
A lack of stakeholder participation also sends a message to the team that the product is not important. That is almost certainly not the case.
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? Do you have trouble getting buy-in from stakeholders?
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.
