Young Jimmy is in 3rd grade. He's constructed an immaculate paper-mâché volcano. It took every spare minute of the last to weeks to make. His mom carefully loads it in the back of the minivan. The anticipation is too much for Jimmy, he can't even look. Arriving at school, Jimmy helps her carry it into the gymnasium, one step at a time, a balancing game like he's never experienced before. Just as Jimmy gets his red and black peaked masterpiece setup in his booth at the Annual Science Fair, panic strikes him. So wrapped up in the architecture and construction of the erupting mountaintop itself, he's forgotten the vinegar and baking soda at home. "No worries," he thinks to himself, he took plenty of pictures during the test runs, "I'll just post the pictures up in my booth and the judges can see how absolutely perfect my volcano is."
When you have many teams working on one product, having each team present and show their portion of the increment could take hours. And some stakeholders are only interested in certain portions of the product, and feel as if their time is being wasted in long Sprint Reviews. One technique that remedies this situation is the Science Fair or Bazaar. I'm seeing and using these more and more for Sprint Reviews.
The concept is simple. The PO kicks off the Sprint Review with everyone's attention. She might go over the product vision, roadmap, state of the marketplace, and highlight significant new features delivered in the last Sprint. Then she dismisses the massive group and invites them to find teams they wish to talk with more in depth. The teams are lined up on the outer edges of the room (or in separate meeting rooms, hallways, or any free space!), with their team name and core functionality area clearly marked with a sign. They invite stakeholders into their "Science Fair Booth" and walk through the Increment with them, ask for feedback, allow the stakeholders to interact with the product, observe, and thank them as the move on.
This technique is great of massively scaled projects with dozens of teams. Everybody gets an overview of the entire product, but then all the details are left to individual teams. Stakeholders can pick and choose what they want to see, and spend as little or as much time as they wish with the teams. When starting out, I highly suggest that you coach teams to pull in stakeholders actively, just like merchants at a bazaar, coaxing them to come and interact with the product and give feedback. As a new technique, sometime people just need a little nudge in the right direction. Get excited for showing off your product, just like Jimmy. Speaking of Jimmy....
As Jimmy is putting the finished touches on his arrangement of photographs, he spots Susie setting up next to him. Now Susie has always been just a bit behind Jimmy in school, always getting the second best marks, always finishing the race just behind Jimmy. Her volcano is a solid specimen, certainly, but nothing compared to the pixel-perfect replica of Vesuvius that Jimmy made. Susie, however, has remembered he vinegar and baking soda. As the judges make their rounds, Susie carefully measures out the exact ratio of ingredients, sets up her volcano, and at just the right moment: SWOOSH!
Guess who wins the blue ribbon?
Regardless of the Sprint Review format you choose, remember this: you have to actually show your done, working Increment of product. You have to actually "pour the baking soda and vinegar together." No pictures, no screenshots, no mockups, no prototypes, no talking endlessly. Show your work. This is your chance to show what you've built. This is what builds trust with stakeholders, and allows you to collaboratively inspect the product, and adapt for the next Sprint. Luckily, product development isn't as messy as paper-mâché. Well, rarely.