Rock That Sprint Review!

Every neophyte Scrum Master loves facilitating Retrospectives. Though I’ve been in the game for awhile, I’m not gonna lie, it’s one of my favorite events too. Why do we love it so? Because it lets us to be creative. There’s the standard Stop-Start-Continue, but you can also roll with one of many other techniques. I’m a fan of the Sailboat Retro, but check out joints like Fun Retrospectives, Retromat, Tasty Cupcakes, or even what’s become canon on the subject, Agile Retrospectives. These resources offer structure, and plenty of alternate ideas. Even Amazon has books on the subject, but check out the results when searching “Sprint Review” vs. “Sprint Retrospective.” You don’t get the same prevalence of materials.

Maybe it’s just me, but I haven’t seen the same zeal, creativity, or enthusiasm in the community for Sprint Reviews, like there is for Retrospectives. In my experience, they’re run as a never-ending parade of developers, each showing off lines of code, and droning away in technobabble. Now that sounds like a party, right?

If you’ve been following along, you know that I used to work in a large, aggressively-corporate IT organization. Back then, when the powers-that-be elected to roll with Scrum, a random project manager (who quickly earned the nickname “Scrum Lord”) was put in charge of overseeing our three Scrum teams. Come time for Sprint Reviews, someone inevitably said the word demo, which set the Scrum Lord off on a rant.

“It’s not a demo!” he insisted.

“OK, then what is it?”

“It’s a review.”

He didn’t see the frustration that the non-explanation caused. Defining a term with itself is a form of circular reasoning, and can drive people insane. Unfortunately, since the Scrum Lord became the first one to earn his CSM (possibly even the first in the company), he became the de facto “expert” on the subject. Also, his insistence on including PowerPoint presentations made my eye twitch. The biggest issue was that he never coached, or explained things in terms that people could understand.

Sadly, that’s not exclusive to any single organization. How many times have you experienced folks who impose Scrum to the letter while waving an iron fist? Without true understanding, you get things like Zombie Scrum, or ScrumBut. Our industry runs rampant with them. Just ask Martin Fowler what he thinks about the Agile Industrial Complex. Nevertheless, that was my introduction to Sprint Reviews.

The trick is not to get hung up on the demo part. It’s perfectly fine to give a demonstration of what you’ve built, but it’s more than that. Most importantly, a Sprint Review is about getting honest feedback from the people who asked you to build something. I’m paraphrasing, but for me, Dan Rawsthorne said it best…

“A Sprint Review is a discussion with the people that have a vested interest in what teams are building, often involving a demo to evoke feedback.”

Here’s the thing. Stakeholders don’t have intimate knowledge about what teams do on a daily basis, nor should they. However, the Sprint Review is the one time when they’re allowed to see the man behind the curtain, and check out what everyone’s been doing for the last two weeks. They should be encouraged to ask questions, express their opinions, and be a general pain in the ass, but only at this Scrum event.

When it comes to running a Sprint Review, you can take from 5 Characteristics of a Great Sprint Review by Barry Overeem, An Agenda for the Sprint Review by Mike Cohn, or How to facilitate an awesome Sprint Review in “Bazaar mode” by roland flemm. No matter how you roll with it, the most important thing to get is feedback. I run mine a bit different. Think back to when you were a kid. Do you remember story time?

For me, childhood often holds the simplest solutions. Adults have an annoying habit of complicating things. With that in mind, remember how during story time, the kids would crowd around the storyteller, mesmerized by each page flip? They’d hang on every word, laugh at the funny bits, gasp as the scary ones, engaging with the storyteller. When the story was over, they’d ask the children, “What’s was your favorite part?”

That’s pretty much how I try to do it. Show, and tell. Be engaging. Ask ’em what they think. Specifically, I encourage the Product Owner, and each developer with something to show to take on the role of storyteller. Public speaking is a skill that everyone should have. Because it’s a mixed crowd, it’s important for people to speak like they’re talking to a sixth grader, or to their grandparents. Not because the audience is filled with idiots, but so that the story is clear. Rather than rattling off a slew of met requirements, or dig into lines of code, they bust it out in simple terms, while keeping it conversational.

And for those who aren’t sure, the PO should be the one hosting this jam.

“Hey, everyone. We finished that thing you asked us to build. The team won’t confound you with technobabble, but they’re gonna give you the highlights. After that, play around with it, and try to break something.”

After each overview, and demo, stakeholders are asked for their input. This is the bit about eliciting feedback.

“What did you like about it?”

“What did you hate?”

“Anything you’d change?”

“Did we build the right thing?”

I’ve also been known to hand out Post-It Notes for stakeholders to write down their thoughts (just peep my Scrum Master toolbox to see what I mean). This feedback in small bites can be collected, and shared at the end to kick off further discussion. Since users, and stakeholders weren’t around during the day-to-day (or rather, strictly forbidden), it’s a good idea to make them aware of anything that popped up during the sprint.

“Also, some sh*t happened last week that impacted our work. Two team members were out with the flu, and the development servers went down for a few hours, so we lost a little bit of time.”

Then there’s that bit about what’s coming up in the backlog. If you’ve already held your Backlog Refinement session(s), this part should be a breeze.

“Oh, and here’s what we’re looking to tackle next. We still good? Cool, see you in two weeks.”

Thanks to the old-school configuration of office buildings, I know it’s not always possible to avoid utilizing conference rooms. But when everyone’s gathered around a large, conference room table, it’s easy to fall into a pattern. Developers switch off who’s connected to the projector, or large monitor, and share what they’ve built. The Sprint Review then falls into the category of boring, repetitive meeting. Everyone sits solitary. Like story time, it’s important to make it more intimate. Get folks to huddle around a single screen. Make people move.

That’s how I try to roll with Sprint Reviews. It’s not perfect, and by no means the only way to facilitate them, but it’s part of my dance. How do you rock your Sprint Reviews?