top of page

How to Facilitate an Outstanding Sprint Review in “Bazaar Mode”

Updated: May 11

Review Bazaar is one of the Elevating Katas that help to elevate your organization to the higher archetypes:


ree


This article aims at helping you to conduct the most awesome Sprint Review 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 (PART-3, PART-4, and WHOLE-3 and WHOLE-4).


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 next in the queue...




ree

We can do much better than this


The Sprint Review is supposed to be a thorough inspection of working software. Sitting in a room looking at slides or screenshots will not 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 will we 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 the happy flow.


In addition to inspecting the product, teams need to share their status and provide insight into their learning ability with stakeholders by discussing the challenges they face. This elicits collaboration because the people funding the teams benefit from getting the teams unstuck. The Sprint Review is an opportunity for stakeholders to interact with the teams to learn what 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 particularly well with CAPS-3 and PART-3 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 involved in the product development process or who consume the delivered value. (Don’t invite real customers randomly, since lack of context can hinder the Sprint Review.)


Make sure the PO announces which features will be inspected so stakeholders can decide if they should join. Most importantly, don’t forget “the one who pays the bills,” like the CEO. Knowing they’ll be there adds healthy pressure. But for your first Bazaar, don’t push too hard—treat it like a rehearsal. When it works, word will spread.


Don’t focus the Review on teams doing their dance—shape it around delivered features. This might require members from different teams (especially in CAPS-2 or PART-2 contexts) to collaborate on a single inspection of end-to-end functionality. That means preparing a workshop or hands-on session, observing the visitors, and engaging in feedback dialogue. Combining multiple team Reviews makes the session more valuable for stakeholders. They can visit one event and get updated on multiple investments.


Core Concepts of the Bazaar:


1. Parallel inspections. Each delivered feature gets a "shop." Attendees choose two shops to visit per Review.


2. Instant transparency. Teams clarify feedback, provide a rough complexity estimate. The PO shares what will happen next: act, refine later, or discard.


Preferably, hold the Review in your regular workspace. The development time is over, so no one is “missing work.” A dedicated room is fine, but not required. Just space the shops out well. Teams should create big banners naming the feature and shop.


For remote participation, use a good meeting room with strong AV equipment. A local facilitator is key to success here.


To ensure quality, plan prep sessions with the PO and teams. The Scrum Master and PO are critical in asking the right questions and raising the bar.


Stick to the standard Sprint Review timebox. Don’t overextend. The Scrum Master must facilitate strongly.


Arrange a whiteboard, projector/screen, snacks, drinks—keep it informal and engaging.


Step-by-Step Format


The Sprint Review is hosted by the PO. The SM facilitates.


Start on time. Always. Even if no one shows up.


5-minute Welcome – PO welcomes stakeholders and teams, recalls Vision and Sprint Goal. Keep it focused on the delivered software. No ops updates.


5-minute Intro – SM explains the agenda, hands out sticky notes and pens, reminds attendees to give feedback, and keeps the strict schedule.


5-minute Feature Pitches – A member from each team pitches their feature shop. One-liner format.


ree

20-minute Review Round 1 – Stakeholders visit a shop, interact, give feedback. Teams observe and self-organize to prioritize.


10-minute Feedback Merge – Everyone regroups. PO invites feedback. SM clusters stickies. Others can help—this goes fast.


20-minute Review Round 2 – New shop visits. Teams rotate roles—observers become visitors. This fuels cross-team learning (especially useful for CAPS-2 and PART-2 environments with incomplete teams). PO organizes Round 1 feedback.



ree

10-minute Feedback Merge – Another group feedback session. PO emphasizes inputs that affect the next Sprint. Business stakeholders are invited to speak in the group, not one-on-one.


10-minute Break – PO and SM to organize the acquired feedback of round 2 and prepare for the close.

ree

15-minute Conclusion – PO elaborates on collected feedback, grouped by feature. Team members give context and rough estimates. PO explains which feedback will be acted on and thanks participants.


20-minute Informal Wrap-up – Space for 1-on-1 questions, clarifications. SM runs a quick ROTI to inspect the Sprint Review format itself.


Awesome, right?


Try the Sprint Review Bazaar once. Evolve it. Do it again. If your teams are at CAPS level today, this Elevating Kata helps them practice PART-level collaboration.


Your teams and stakeholders will never want to go back.

Roland Flemm & Alexey Krivitsky for Org Topologies™



Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating

Org Topologies Academy

Thank you for subscribing!

bottom of page