Sprint reviews are a built-in way to engage stakeholders in a project every few weeks, at a minimum.
The sprint review meeting is when teams can talk about the functionality they have created with the people who need and want that functionality.
This means 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' attend, are bored, or sit passively just waiting for the meeting to end.
Sprint reviews are a vital time for collaboration.
So let's look at some ways you can make sprint interviews interesting and engaging.
By the way, my name is Mike Cohn, and I'm the author of three bestselling books on Agile and Scrum.
I help good teams become great teams.
To ensure sprint reviews are well attended, choose a good time and day for the meeting.
Sometimes reviews were poorly attended simply because the meetings is at a bad time or on a day.
I worked with a team that ran one-week sprints, ending every Friday.
They scheduled their reviews for Monday at 10am.
This was a horrible time.
Mondays already had more than their share of meetings, and 10 am was prime time for other meetings.
No one wanted to be the jerk who scheduled a 9am meeting, so 10am had become the default for the first meetings of the day.
After shifting their view to the afternoon, everyone could attend.
If your stakeholders aren't attending your sprint reviews, maybe they find them boring.
This can happen when a team demos everything it did during the sprint.
There's no need 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 it, but stakeholders 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 a strong majority of the participants need to hear that much detail.
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, and then move on.
You can also make reviews more engaging by handing the keyboard or screen sharing to a stakeholder.
have them take a new feature for a spin while a team member talks about it.
Stakeholders may not be attending your sprint reviews because they don't understand why they need to participate.
Unless you've explicitly communicated what happens during a review, how stakeholders will be involved, and what decisions will made,
stakeholders may see a need not to attend.
To encourage stakeholder participation, I like to send an agenda the day before each meeting.
In it, i list the sprint goal, the product backlog items that will be discussed, and the key decisions to be made during the review.
This helps stakeholders decide if they should attend.
I remember a review in which a team planned to show off usability improvements they'd made.
An important stakeholder with no expertise in usability decided she wasn't needed in the meeting, I think this was the right decision.
That stakeholder did not need to waste her time in a meeting to which she could not contribute.
She did participate in the next sprint review because her opinion was important to the work of that sprint.
Letting stakeholders choose to skip reviews in which they're not needed is a win because stakeholders learn that the team respects their time.
One reason stakeholders may not participate in sprint reviews is that the meetings take too long.
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 figure that out in advanced.
I'm a big fan of this showbiz adage from P.T.
Barnum, always leave them wanting more.
Leave sprint review attendees 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 then every little detail of something new.
If you're asked, demo the remainder.
Always leave the wanting.
More.
Good for show biz, good for a sprint.
Review.
Sprint reviews should be conversations, not presentations.
If you don't ask stakeholders to share their opinions, don' t be surprised if they stop participating.
You don t need to act on every stakeholder's suggestion, but team members need consider each.
If stakeholders are reluctant to share opinions, start by explicitly asking for their opinions as you demo each backlog item.
If that's not enough, 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 might prefer something different.
Often, once you get feedback started, others will add to it.
Encourage future stakeholder participation by trying as quickly as possible to incorporate some of the stakeholder feedback.
When you do, point out that the change came as a result of their feedback It's a serious problem when stakeholders fail to participate in sprint reviews.
It leads to missteps being caught later in the process, sometimes so late the 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 I've shared should help you overcome the most common reason stakeholders are not attending your sprint reviews.
If you found this video helpful, please do me a favor and hit the like button.
It really does help YouTube know to show it to others.
And click the subscribe button if you'd like to be notified of future tips.