How satisfied are you with the outcome of your Sprint Reviews?

If you’d asked me this question years ago, I’d say not satisfied at all. I had to hunt stakeholders to attend the event, and getting their full attention was mainly impossible. Not to say developers despised the session.

Does that ring a bell to you?

It took me some time to realize the problem wasn’t with stakeholders or developers but with how I ran the show.

Let me tell you why many Sprint Reviews suck and how you can fix it.

The Boring Sprint Review

Most review sessions lack interaction. It’s like a presentation that helps nobody. None of the following formats will get your audience engaged:

Jira review: The Product Owner opens Jira and walks stakeholders through ticket by ticket. That’s not a review but a status report.
Feature factory: Product Owners present a set of features and tell stakeholders how the features work and how to use them but don’t say why that matters. Apart from this problem, developers are passive and miss the credits.
The secret: Only a selected part of the team and stakeholders attend the event. Agreements take place there, and communication gets distorted. You can only expect a broken phone result.

I must be straightforward: All the above are the wrong ways of running Sprint Reviews. It’s supposed to be an engaging working session with valuable outcomes, not something everyone wants to run away from.

Now, let me help you fix it.

What Can You Do Today for a Better Tomorrow?

I have a simple recipe for Sprint Reviews. Yet, to come to what I’m about to share took me at least fifty bad sessions until I got it right. Maybe I was just stupid, but anyways. I will give you my five steps to a valuable Sprint Review.

Set the stage: The Product Owner starts with the Sprint Goal, why that mattered, and shares a brief Sprint overview. Also, share whether the Sprint Goal was reached. It’s essential to keep it short and sweet. No longer than 2 minutes.
Run the show: As the stage is set, the Product Owner hands over to the Developers and lets them present the Sprint Result. At this moment, the Product Owner becomes an observer. This part should be brief, with a high level of results—no more than 5 minutes.
Give stakeholders a mission: The critical part is this step. Developers prepare a scenario and assign stakeholders an assignment. Ask them to get something done with the Sprint Result and observe how they interact with it.
Learn from their behavior: The whole Scrum team pays close attention to how stakeholders use the product and what they struggle with to reach the assigned mission.
Ensure understanding: The Product Owner ensures understanding by naming what’s observed. For example, “You couldn’t proceed with the task because you didn’t understand A as you expected B. That made you confused.” Somethings you will get wrong, and the stakeholder will correct you. That’s when you ensure understanding.
Make agreements: Don’t let that sync—set agreements and expectations. Decide what to address and what not to.
Give a glimpse of the next Sprint: As you’re concluding the Sprint, shed light on the upcoming Sprint. I’m not telling you to say which features you’re delivering but the direction you’re taking and why that’s important.

I hope that helps you.

I learned that the more interactive you make the Sprint Review, the more valuable it becomes. Take proper time for preparation to ensure it’s valuable for your audience.

A Question for You

How would you perceive the value of your Sprint Reviews if you were a stakeholder?

Worth Reading

Note: Recently, I released a crash course about Product Discovery. You may be interested in knowing what successful companies do to create value sooner.

Untrapping Product Teams

Stakeholders couldn't care less about Sprint…