Review Bazaar is one of the Elevating Structures that help to uplift your ecosystem up the levels of the Org Topologies™ mapping:
This article aims at helping you to conduct the MOST AWESOME Sprint Review that people have ever witnessed. An additional benefit of the Bazaar mode: it works with large crowds, so ideal when you work with multiple teams on a shared initiative. This type of Sprint Review approach is commonly used in the higher archetypes as per Org Topologies™.
The main purpose of the Sprint Review (SR) is to collect feedback. After seriously inspecting the product, several changes to the backlog or action points for solving impediments should be identified.
The Scrum Guide says:
“During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."
You must have witnessed them at least a hundred times: those Sprint Reviews where each team gets their moment of fame to broadcast what they have been sweating on over the past couple of weeks. How disappointing it is to look at PDF documents, PowerPoint, 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 silence. The hurdle praises the demo with a dutiful round of applause. Of course, they do; They are the next in the queue...
We can do much better than this.
Foremost, the Sprint Review is supposed to be a thorough inspection of working software. Sitting in a room looking at 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 users should get hands-on with the product and the developers should observe them. (Read that again!) Only then we will collect sensible feedback. The attendee will click the wrong buttons, 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 provide insight into their learning ability with the stakeholders by discussing the challenges they face and are facing. This will elicit collaboration because the people funding the teams 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”. This works with cross-functional feature teams working on a single backlog managed by one PO. That makes things easier, but having multiple backlogs and multiple POs 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 or consume the value delivered. Note there is no use to start inviting real customers randomly, since not having any context will lead to hindering your Sprint Review with questions that should be addressed in other sessions.
Make sure the Product Owner announces which features will be inspected 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's 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 dressed 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 prepared a workshop or a hands-on session to inspect a feature they helped to deliver, observe the visitors, and engage in a dialogue. By combining multiple Team Reviews in one session, the session becomes much more valuable for Stakeholders to come to. By visiting one meeting, they can get updated on the value delivered on their Investment.
The first 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. Ensure to create the opportunity for people to visit two shops per Sprint Review.
The second main concept of the Sprint Review Bazaar is to provide instant transparency on the feedback collected. The Team members will comment and clarify the feedback they collected and will give a "ballpark figure" regarding the complexity of the suggestion. The PO can then share what he will do: Put it on top of the Backlog, add it to another item that will be refined later, or not pick it up at all.
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. 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 collaborating in the Sprint Review 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 to make the remote contribution successful.
To prepare and verify the quality of the Sprint Review, 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 is required!
Arrange for a whiteboard, a projector or large screen, snacks, and drinks, and create an informal atmosphere.
Here we go!
The Sprint Review is hosted by the PO. The Scrum Master (SM) facilitates.
Start exactly on time. Even if nobody shows up.
5-minute welcome: The PO welcomes the stakeholders and the teams. He remembers the vision, Product goal, and Sprint goal as they were set at the start of the sprint. Take care to keep the focus on the delivered software and work done and do not abuse this meeting for any managerial or operational updates; This is not the information the attendees came for.
5-minute introduction: SM introduces the Review agenda, hands out stickies and pens to every attendee, remembers attendees that we are looking for feedback, and keeps a strict 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 (work in the shops) and merge (join again).
5-minute pitching of all features: For each feature that will be inspected, a team member gives a short pitch (one-liner) of what attendees can expect to learn in their “shop”.
20-minute Review round 1 (diverge): All attendees visit one shop, work with the product, and generate feedback. Most of the time, a team member will aggregate or prioritize their findings (self-organization) for their shop.
10-minute feedback (merge): In front of everybody assembled, the PO asks what has been learned, and randomly picks people to share their feedback. The PO needs to do this, to ensure a proper mix of people get to do 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-minute Review 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. Cross-team learning here is immense. The PO works on organizing the collected feedback from round 1.
10 minutes feedback (merge): 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, the PO must address 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-minute break: Time for the SM and PO to organize the acquired feedback of round 2.
15-minute conclusion: The PO elaborates on the collected feedback. The feedback is grouped and clustered per feature. Preferably the team member who collected the feedback gives context and a rough estimate of the work. 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 upon for solving impediments. If there weren’t any, the PO addresses this too. Finally, the PO thanks everybody, for their contribution.
20-minute wrap-up: Time for informal talks. The PO will use this time to gather more details or to make appointments to elaborate on some of the findings.
End exactly on time. On the way out, the SM collects feedback on the Sprint Review by doing a ROTI (return on time invested) to further improve the format of the session.
Awesome, right?
Roland Flemm & Alexey Krivitsky for Org Topologies™
