How to Facilitate an Awesome Sprint Review in ''Bazaar Mode''

The main purpose of the Sprint Review (SR) is to collect feedback. After seriously inspecting the product, a number of changes to the backlog or action points for solving impediments should be identified.

The Scrum Guide says:

"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."

You must have witnessed them at least a hundred times: those Sprint Reviews where each team gets their moment of fame to show off what they have been sweating on over the past couple of weeks. How disappointing it is to look at PDF documents, PowerPoints and wiki-pages full of awesome designs or other fantasies the team spent the CEO's money on. Someone occasionally asks a polite question to prevent awkward silences. The herd of brain-dead sheep praises the demo with a dutiful hand of applause. Of course, they do; they are the next in queue, inept at presenting anything in front of large crowd, excelling at boring the hell out of us.

"Show Me Some Value or Go Home!"

Foremost, the SR is supposed to be a thorough inspection of working software. Sitting in a room looking at dull slides or screenshots will not very likely spark a creative buzz. Did you ever do a successful inspection of anything without being allowed to touch it? No. So people should get hands-on with the product and the developers should observe them. Only then we will collect sensible feedback. The attendee will click the wrong buttons, will browse back, refresh, and do everything else you can imagine that was not included in our happy flow.

In addition to inspecting the product, teams need to share their status and give insight into their learning ability with the stakeholders by discussing the challenges they faced and are facing. This will elicit collaboration because the people funding the team have a benefit in getting the teams unstuck. The Sprint Review is an opportunity for stakeholders to interact with the teams to learn which decisions they can take to maximize their ROI.

There are various formats for conducting a Sprint Review. I have tried some with different rates of success. The format that worked best for me is the Sprint Review "Bazaar" or "Science Fair." In most cases, I work with cross-functional feature teams working on a single backlog managed by one PO. That makes things easier, but having multiple backlogs and multiple PO's will not prevent you from having a successful Sprint Review Bazaar.

The Tips

The Product Owner (PO) needs to invite the right people. All teams belonging to a tribe or department, working on the same product or value area should be present. Invite internal and external customers who are in some way involved in the product development process. Note there is no use to start inviting real customers randomly, since not having any context will lead to hindering your SR with questions that should be addressed in other sessions. Make sure you announce which features you will be inspecting in an invitation (e-mail or Slack or whatever you use) so your stakeholders can decide if these features are important enough for them to join the Sprint Review. Most importantly, don't forget to invite "the one who pays the bills," being the CEO or some other company hot-shot. Knowing that the CEO will participate improves Sprint Review quality because it puts healthy pressure to perform on your teams. Note that for your very first Sprint Review Bazaar, don't push too hard on getting those stakeholders in. Your second Sprint Review Bazaar will be better. See it as a dress rehearsal. When successful, the word will spread, and you will get traction.

Don't focus your Review on teams doing their dance, but shape your Sprint Review using the delivered features. This might require members from different teams to collaborate on inspecting a single feature. Inspecting means that a couple of team members do a workshop or hands-on demo for a feature they helped to deliver, observe the visitors and engage in a dialogue.

The main concept of the Sprint Review Bazaar is that you run multiple inspections in parallel. For each delivered feature, create one "shop" in your bazaar. Attendees of the Sprint Review need to choose which shop they want to visit. People can visit two shops per Sprint Review.

Preferably, have the SR in the regular working place. The time box available in the sprint to do the development work is over, so nobody is doing anything else anyway. A separate dedicated location is fine, too, but not necessary. Ensure your "shops" are not too close to each other, so that the people do not disturb other shops working close by. Let the "shop members" create a big banner with the feature name on it for people to know what they can learn in each shop.

If you have people cooperating in the SR from a remote location, then use a closed room (a meeting room) that is sufficiently equipped with remote meeting gear for the remote team to interact. A local facilitator is required to help making the remote contribution successful.

To prepare and verify the quality of the SR, I always plan for preparation sessions with the PO and the teams to focus on the content of their presentations. The Scrum Master and PO play an important role in asking the right questions to get the performances at the desired quality level.

Plan for the regular time-box as prescribed by Scrum. Don't be tempted to make it any longer. Strong facilitation of the Scrum Master required!

Arrange for a whiteboard, a projector, or large screen, snacks and drinks, and create an informal atmosphere.

Here We Go!

The SR is hosted by the PO. The Scrum Master (SM) facilitates.

Start exactly on time. Even if nobody shows up.

5 minutes welcome: The PO welcomes the stakeholders and the teams. He remembers the sprint goal(s) or release goal as set at the start of the sprint (committed work). He might shortly bring relevant events to memory. Take care of keeping the focus on the delivered software and work done. Do not abuse this meeting for managerial or operational updates; this is not the information the attendees came for.

5 minutes introduction: SM introduces the SR agenda, hands out stickies and pens to every attendee, and reminds attendees that we are looking for feedback and keeps a strict time schedule; the SM makes sure there is a big countdown timer or rings a bell when a time-box expires. The SM actively gets people to diverge and converge.

5 minutes pitching all features: For each feature that will be inspected, a team member gives a short pitch (one-liner) what attendees can expect to learn in their "shop."

20 minutes SR Round 1 (diverge): All attendees visit one shop, work with the product and generate feedback. Most of the times, a team member will aggregate or prioritize their findings (self-organization) for their shop.

10 minutes feedback (converge): In front of everybody assembled, the PO asks what has been learned, randomly picks people to share their feedback. The PO needs to do this, to ensure a proper mix of people get to have their say in a structured way. While the PO collects feedback (per shop), the SM groups the stickies. People will come to help them out as this is little time for lots of stickies.

20 minutes SR Round 2 (diverge): During the second inspection round people have the opportunity to visit another "shop." The team members who were facilitating in Round 1 now must go and visit other shops. Other team members will take care of the facilitation. It's great for teams to attend other teams' workshops. The cross-team learning here is immense. The PO works on organizing the collected feedback from round 1.

10 minutes feedback (converge): Another round for the PO to ask attendees what they have learned. The PO should focus on feedback that will impact the upcoming sprint backlog. The PO should also make sure team members and stakeholders have their say. In addition, in this round, it is very important that the PO addresses the CEO or most important attendee directly to share their opinion. They need to share their thoughts in front of everybody rather than in one-on-one conversations.

10 minutes break: Time for the SM and PO to organize the acquired feedback of round 2.

Collected Feedback

15 minutes conclusion: The PO elaborates on the collected feedback. The feedback is grouped and clustered per feature. If possible, the PO shares what he will do with the feedback and explains his choices. He highlights the feedback that will be picked up in the upcoming sprint and names the action points that were agreed for solving impediments. If there weren't any, the PO addresses this, too. Finally, the PO thanks everybody for their contribution.

20 minutes wrap-up: Time for informal talks. The PO will use this time to gather more details or to make appointments to elaborate some of the findings.

End exactly on time. This is a busy day: Sprint Retro's coming up. On the way out, the SM collects feedback on the SR by doing a ROTI (return on time invested).

Awesome, right?

Roland Flemm

Want to get more awesome tips? Participate in one of my classes (click here to see an overview and register) I will be giving this Automn in Utrecht.