Your Sprint Reviews suck, and that's why!

Do you have the impression that your Sprint Reviews suck, that they are a waste of time? 

Are you missing real users, are attendants squirming for the meeting to end as soon as possible - or have they found something else to do with their time that has more value, for example counting the holes in the ceiling?

Or is your Review already a sausage party where nobody except team members attend, because everyone else has decided to vote with their feet?

I've sat through many a Review, and found some common patterns that have a high tendency to lead to terrible Sprint Reviews.

In this article, I list some of the most egregious sins and how to avoid them. 

Sin #1 - Activity Reporting

Imagine you're going to a Genius Store, looking for the newest features on the latest iPhone - and the salesperson starts by saying, "We set up a new chip factory, but it was a lot of trouble to buy the grant for the land, to get a building permission, and you know all those new building regulations - we had to hire a whole department of lawyers just to go through the paperwork, and then there was that issue with ..." - for heaven's sake, you'd run out of that store screaming, never to return!

And yet, that's what teams consider a "normal" thing to do during Sprint Review. Why? Let me formulate the intention of the Sprint Review as a User Story, using the Connextra Template:

As a user of your product, I want to know about the latest changes so that I can decide whether I like them.

That's all a user wants to know. If this is not the #1 top priority of your Review, you have nothing to say and are wasting everyone's time.

The fix? Think what a Review from that fancy new (insert product) would look like for you to want to attend. Not the Behind the Scenes - the Product Review Session that you would pay to get a ticket for! Like, BlizzCon, for example! And then, move your Reviews in that direction.

Quick fix: Forget about YOU. Talk about THEM (the customer!) and their needs in terms of the Product!

Sin #2 - Ticket Management

When the team whips up their ticket management first thing upon starting the Review, I already know it's going to be a waste of everyone's time. Regardless of whether that tool is Jira, Excel, Trello or whatever - I know that this team can't think from a user's perspective.

Seriously, would you come to this blog if you had to first click through a summary of the work I did before you could find out about the content I produced? Probably not. And that's how users feel when you confront them with the work you did.

Rather than describing what work you did, you should start with something called a "value proposal". Let the users know very briefly why they're here, what they're going to be investing time into and which benefit they're going to get out of this. If this hasn't been achieved within the first minute, you might as well stop and cancel right there.

Quick fix: Forbid the use of ticket information during the Review.

Sin #3 - Powerpoint

Yet another great indicator of a Review that is going to suck is that the center of attention is a slide deck, not the product itself. When I see slide decks and no usable software, I immediately make a mental note, "The team doesn't know what is useful." While in some rare cases, Powerpoint has a beneficial effect, our usual text-filled or bullet point lists describing details are a great method of getting people to divert their attention elsewhere.

The center and focus of attention of the Review is the Product and the User. Everything else is secondary or irrelevant. If you can't show it in the Product, you better have a damn good explanation why it's relevant for the user!


Quick fix: Forbid the use of Presentation software during the Review.

Sin #4 - Disconnect

When users can't see why they benefit from the items the team has completed during the Sprint, there is a deep rooted problem somewhere in how the team works. This can't be fixed in the Review, and the Review is neither the place for the team to earn sympathy points from the users, nor is it the place to brag about how much work you achieved.

The Review is a synchronization point between team and users, where users learn what's new in the Product and where the team leans how users like the new features. If this synchronization is broken, the Review is pointless.
When the Review becomes a show where the team demonstrates themselves, their work or their outcomes without actively listening to the Voice of the Customer, you might as well scrap the Review.

Quick fix: Make user statements in the Review lead to real change in process and product.

Sin #5 - No Action

At a minimum, I, as a user, attending a Review, expect to see Real Action with the product. I may not expect something fancy, but I expect to see how the Product works. Preferably, I expect to fiddle with it myself. When I don't see the Product in Action, I haven't seen anything. And I have wasted my time.
I can form my opinion best when I get hold of the tablet/mouse/keyboard connected to the Real Application, but when this isn't possible, I at least want to see what the product looks like. In descending order of catching my interest as a user are:

• #1 - I get to use the product
• #2 - I see you using the product
• #3 - I see a video of someone using the product
• #4 - I see pictures of the product
  ....
• #999999998  - I hear you talking about what the product can allegedly do.
• #999999999  - I don't even get that.

Quick fix: Hand the product to the user and see what happens.

Sin #6 - Filling the timebox

Another great way to waste people's time is to feel pressured to use the Review's timebox. If you only have a 5-minute topic, the Review can be over in five minutes. Keep it short and simple. Get the information out that needs to go to the users, and get the feedback in that you need.

Your users' time is precious, as is yours. Don't extend the Review meeting. If you feel that you have too little to show, that's a great topic for a Retrospective, but no reason to bloat up your Review.

Quick fix: Focus on essentials, keep the Review as short as possible.

Setting up a good Review

So then, what is a good Review?
First, you start long before the Review. You start with the Sprint Planning. What's the team's compelling Sprint Goal? Why is it important? Which user problem are you setting out to solve? What are the individual pieces of the puzzle contributing to solve the user problem (e.g., "user stories")?
How is your solution valuable for the user? What is the users' newfound benefit?
If you haven't thought about this right from the beginning, you won't fix it in the Review.

Tell a compelling Story:

1. What is the user problem you tackled?
2. What is the pain the user has had?
3. What is the solution you provided?
4. How does the user benefit from your solution?

And then - let the user do the talking!