Maarten's Sprint Review Guide V0.8

From Boring Sprint Demo to *Chef's Kiss* 😘 Sprint Review

Let’s be honest: most Sprint Reviews are boring and a mere shadow of the valuable meeting they could be. They become dull affairs everybody on the Scrum Team hates attending.

When you drop the Sprint Review in a conversation, these are some of the most likely responses you will hear:

“Sprint Review? Are you talking about our Sprint Demo?”

“Yeah, I know what you mean. We’re already doing a Sprint Retrospective every Sprint.”

"Oh yeah, we stopped doing that because there were many Sprints where we didn't deliver anything."

Yikes!

The current state of the Sprint Review is so sad that it is often even confused with the Sprint Retrospective. That might be unsurprising when dealing with people who are not Agile or Scrum experts, but I’ve got news for you: including them doesn’t make a big difference in interest in the Sprint Review.

Even experienced Scrum Masters and Agile practitioners neglect the Sprint Review. Do you want evidence to back up these statements? Fine, let’s go!

When you google for Sprint Retrospective templates:

Prepare to enter a world of endless possibilities. There are like 17 Ted Lasso Retrospective Formats, Gremlins, Barbie, and even the Great British Bake-off Retrospective formats. You name it, and it probably exists as a Sprint Retrospective Format, or someday, it will likely exist. Scrum practitioners seem to have a soft spot for Sprint Retrospective formats.

If you perform the same kind of search for Sprint Review templates, you’re more likely to see a tumbleweed pass by than to find an actual template:

Zip. Nada. Zilch. You’ll likely find a few Sprint Review templates after some digging, but most of them will suck. Some are Sprint Retrospective templates mistakenly labeled as Sprint Review templates. Oops!

Why are millions of Scrum Teams worldwide happily using Sprint Retrospective formats, but almost nobody seems to care about the Sprint Review?

That’s the question we should be asking, and I don’t have any answer to that. I do believe it’s time to give the Sprint Review some love 💕!

That’s why I’ve written this handy guide to help you make your Sprint Review more productive, fun, and engaging.

In this guide, we will explore the following question: how can you turn your boring Sprint Demo into a *Chef’s Kiss* 😘 Sprint Review?

I’ve also created a Sprint Review Miro template based on the ideas in this guide so you can immediately hit the ground running. The Sprint Review Miro was released a month ago and received a nomination for Best in Miroverse in the category Agile Workflows.

This Sprint Review Guide will cover:

1. The Purpose of the Sprint Review

2. Sprint Review Guidelines

3. Sprint Review Anti-Patterns

4. Sprint Review Preparation

5. Possible Sprint Review Topics

6. Conclusion and Summary

Let’s start by recalibrating our expectations and discussing the Sprint Review's intended purpose.

1. The Purpose of the Sprint Review

The Sprint Review is probably the most misunderstood Scrum event. Most falsely reduce it to a Sprint Demo where you showcase completed features. I believe it can be so much more valuable and useful than that.

I dislike quoting the Scrum Guide because it creates the impression that it’s the source of absolute truth we should all aspire to follow. First and foremost, we should be firmly anchored in the results we want to achieve. Adherence to the Scrum Guide only matters to the extent it produces the desired results.

But since the way Sprint Review is practiced has strayed away so far from its intended purpose, it’s good to go back to the roots and explore a relevant section from the Scrum Guide:

“The sum of the Increments is presented at the Sprint Review thus supporting empiricism.

However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.” - Scrum Guide 2020 version

To clarify, the sum of the increments is the whole product—not just what you added in the previous Sprint. In an ideal world, what you’ve delivered may already be live before the Sprint Review.

Your stakeholders will have already seen it and, if necessary, been consulted prior to the release. Releasing something provides better information than talking about something we can potentially release, that’s why the Sprint Review should never be a gate to releasing value.

I want to stress that this paragraph of the Scrum Guide is phrased rather poorly. ‘Presenting the sum of the increments at the Sprint Review thus supporting Empiricism’ is an abstract statement. Presenting a product supports Empiricism much less than talking about data produced by the ‘sum of the increments’ aka your product, even of past Sprints.

In short, the Sprint Review should have been called the Product Review. We’re not reviewing the past Sprint - we’re supposed to check how our Product is doing holistically by answering questions like:

• What’s happening in the market? What are our competitors doing?

• How good are we at creating value for our customers, and how do we know that?

• Are we capturing the value we’re creating adequately as business value?

We should talk about the whole value our product is delivering, not just the past Sprint, because results are often lagging. I’ve called these kind of Sprint Reviews, Goldfish Memory Sprint Reviews:

“In the movie 50 First Dates, Adam Sandler falls in love with Drew Barrymore. There’s just a slight hitch — she has amnesia and loses all the new memories she forms when the day ends. This prevents her from falling in love with Adam Sandler for longer than 24 hours.

As a result, every day, Adam Sandler has to start over from scratch and try to win her over again and again, hence the title.

In my experience, many Scrum Teams suffer from the same phenomenon as in that movie — what I’d like to call Goldfish Memory*.

Goldfishes only have a memory that spans a few seconds. The teams act like fishes swimming around in circles every Sprint over and over again to ultimately end up at the same point.

Every Sprint the only thing what’s discussed is the previous Sprint, and the next Sprint their Goldfish Memory repeats.”

Just talking about the previous Sprint isn’t the only problem many Scrum Teams face at the Sprint Review. Unfortunately, since delivery is often such a struggle, the Sprint Review frequently devolves into a Sprint Demo, where we talk about what we’ve done instead of shifting the focus to what we’ve achieved with what we’ve done.

It may seem like a subtle distinction, but it makes a big difference. What we’ve done still matters, but it’s supposed to be a means to an end, not the end itself.

Your effort only matters to the extent it makes a difference for your customers and your business. Your customers don’t know or care how many Story Points or features you’ve completed.

Now that we’ve hammered the point home that the Sprint Review’s primary focus should not just be what we’ve delivered in the past Sprint but trying to take a more holistic view of how your product delivers value, let’s start by providing some guidelines for a great Sprint Review.

2. Sprint Review Guidelines

1. You must tailor the Sprint Review to your context. Do what works best for your situation with the following question in the back of your mind: Are we collaborating in a way that improves our ability to deliver value? The Sprint Review format should provide transparency on the value your product is providing and the best opportunity to inspect and adapt to deliver more value.

2. You don’t have to demo features. Only demo something if you will get reliable and relevant feedback you can immediately act upon. A salesperson giving feedback on your product is not a substitute for actual customer or user feedback.

3. Think outcomes, not outputs. Sprint Reviews often take the teams and what we’ve delivered in the past Sprint as the starting point. Who cares who did what and how much they did? A feature doesn’t deliver value. What it makes possible delivers value, and that should be our primary concern.

4. If it’s not done, don’t demo it like it’s done. It’s okay to show something even if it’s not done to get feedback, as long as it’s crystal clear that it isn’t done and the intent is to get feedback, not create false the illusion of progress. You will not get any points if you answer this in a Scrum exam, but the reality is more nuanced than the black-and-white answers, which easily fit in a multiple-choice format.

5. Keep it engaging and interactive. If it isn’t lively and interactive, then you’re either not talking about the right things, or you didn’t invite the right audience. One-way traffic means you will leave the Sprint Review with the same understanding as before the meeting started, which is bad.

These are some of the guidelines for a successful Sprint Review. I want to stress that you should treat these as guidelines and not as holy principles to follow no matter what. What works in your situation is always what matters most.

Now, let’s explore the Sprint Review anti-patterns you should watch out for.

3. Sprint Review Anti-Patterns

1. Everything is always demo’ed. That most likely means you’re performing delivery theater. People are busy creating and upholding the image that we’re doing lots of work and moving mountains. The point is never to exert as much effort as possible. We actually want to do as little as possible while making as much of a difference as possible. The better we understand what we’re trying to make possible for our customers and users, the better we can cater to their pains, needs and struggles.

2. Scrum Teams don’t have clear goals. This is an anti-pattern in Sprint Reviews because goals provide guidance on what we’re looking to achieve during the Sprint. If we don’t know what we’re trying to achieve, getting helpful feedback from stakeholders is difficult. The Sprint Review will become delivery and timeline-focused instead of concentrating on how we can create even more value for our customers and the business.

3. Lack of energy from participants. If everybody looks like they’re falling asleep during the meeting, they probably don’t consider the meeting valuable. Do we need to make the meeting shorter and discuss fewer topics? Are we discussing issues that the stakeholders aren’t interested in? Every Sprint Review should be helpful, and if it isn’t, then that’s a symptom of something we should investigate.

4. Stakeholders should be talking, curious, and asking questions. If the Sprint Review is not engaging in an interactive, we won’t get the feedback we need from our stakeholders. It must be a collaborative meeting, not a meeting where one party sends and the other only receives.

5. The Sprint Review adds another meeting without reducing other meetings. Ideally, you revisit your plans and roadmap once every Sprint. As the Sprint Review is quite a time commitment, reducing other meetings where timelines and roadmaps are discussed is important. This also prevents back-tracking, where you have to discuss the same topics with different people over and over again and make their difference of opinion your problem.

6. The only things discussed are features and their timelines. Delivering a great product means you're not just in the feature delivery game. More features aren't necessarily better, just like a sentence with more words isn’t better.

7. Canceling the meeting when nothing has been delivered. Yes, we have nothing to show or get feedback on, but that’s definitely something to talk about. It’s an opportunity to be transparent about our challenges so that our stakeholders know why things are going differently than we had anticipated. Plus, we may try to enlist their help in resolving the obstacles that prevent us from delivering something during the Sprint.

Now that we’ve discussed Sprint Review guidelines and common anti-patterns, let’s explore the things you should have in place before doing a Sprint Review.

4. Sprint Review Preparation

The following elements should ideally be in place before you do the Sprint Review:

• Product Goals

• Sprint Goals

• A clear overview of your stakeholder landscape

Don’t worry if you don’t have any of these things sorted out before starting, life often isn’t ideal. Start with what you have and gradually evolve it into something better. If you wait for perfect or ideal, you’ll likely never start.

Product Goals and Sprint Goals are important because they provide guidance on what we’re trying to achieve and allow us to inspect and adapt based on outcomes. At the Daily Scrum, we inspect and adapt based on our progress toward the Sprint Goal. At the Sprint Review, we inspect and adapt based on progress toward our Sprint Goals and Product Goal.

A clear view of your stakeholder landscape is crucial so you can decide who to invite to collaborate at the Sprint Review to maximize value delivery.

To reiterate, don’t worry about getting it perfect from the start. It’s better to get started and adapt as you go along. My preferred approach: start with a single team, and keep it simple, and once you’ve got it working for that team, slowly expand to other teams. Don’t overthink. It’s easy to add things, it’s much harder to remove things. It’s in our human nature.

I want to stress that sprint Goals, Product Goals, and Stakeholder Management are too big to cover in a guide like this, and many books have been written on stakeholder management. I’ve written a book on Driving Value with Sprint Goals in case you want to learn more about Product Goals or Sprint Goals.

5. Possible Sprint Review Topics

I want to stress that please don’t treat this as the definitive list of things to cover during the Sprint Review. Instead, see it as a dinner menu you can select from.

And to re-iterate: please start small. As human beings, we tend to overcomplicate things, and it’s better to start small and evolve based on what we discover and learn than to start big based on what we thought we knew before starting.

It’s easy to discover something that’s missing. It’s much harder to uncover something that’s unnecessary.

Here are some of the topics you can decide to cover during the Sprint Review:

• Sprint Review Purpose

• Product Goal & Sprint Goal

• What’s going well and challenges

• Product Demo (optional)

• How’s our Product Doing?

• What’s up next?

• Room for feedback & Discussion

We start the Sprint Review with our agenda so everybody has clear expectations for what’s coming up. We then remind everyone what the goal of the meeting is so we’re all on the same page about what is expected from each of us. Over time, everybody will know, and there’s no need to explain, as people will get the purpose from seeing what we’re talking about.

We then discuss the current Product Goal and Sprint Goal(s), as these are what we’re trying to achieve with our Scrum Team(s). Did we achieve our Sprint Goals? How is our progress toward the Product Goal?

Then, we discuss what’s going well and the challenges we face as a Scrum Team. The goal isn’t to be exhaustive or do a Sprint Retrospective before we actually have one. We want to provide transparency to our stakeholders on how we’re doing as a team, as influential stakeholders may be present who may help resolve obstacles in the way of them getting what they want as swiftly as possible that we may use to our advantage.

There’s room for a Product Demo, but we don’t have to show everything we’ve completed to show how busy we’ve been or create trust that it works. That’s not what the Sprint Review is for. Only show something when you expect feedback from the people who are present to make it even better. If you have to show how it works for them to trust the quality of your work, then there’s something to work on.

After the demo, you can explore how our product is doing, not by discussing features or delivery timelines but by examining product metrics. Is what we delivered in the previous Sprints moving the needle? Are we achieving the outcomes we set out to achieve?

This is what we should spend most of our time talking about at the Sprint Review, as otherwise, we’ll be stuck focusing on delivery theater and simply living from Sprint to Sprint, suffering from goldfish memory at our Sprint Review.

Everybody always wants to know what we will be doing next, so we show our roadmap and discuss the upcoming draft Sprint Goal we’ll be working towards. It’s crucial that everyone understands the Sprint Goals may still be subject to change (as they’re finalized during Sprint Planning), but since Sprint Goals are still subject to change after Sprint Planning, it’s crucial to manage those expectations.

The Sprint Goal is basically the most important thing we could be working towards, and it’s vital to explore with your stakeholders whether they also believe this is the most valuable thing we could be working towards so you’re all on the same page.

It’s essential to leave sufficient room for feedback and discussion, especially in the beginning, to check whether you’re getting the expected value out of the Sprint Review.

6. Conclusion and Summary

Everything written in this guide is exactly that: a guide. It’s up to you to figure out what works best for your situation. Nobody can provide you with a definitive recipe to follow for knocking the Sprint Review out of the park.

It’s up to you and your stakeholders to discover what works, and I hope this guide will help by providing some pointers. I intentionally did not provide concrete examples. If you want those please check out my Miro Sprint Review template.

Many Scrum Teams focus on delivering features and demoing them at the Sprint Review. It’s important to stress that getting to ‘Done’ every Sprint is a significant step forward, but it isn’t nearly enough.

I like the way Paddy Corry phrases it:

“ ‘Done’ is only the start of the journey. ‘Done’ helps us to learn from customer feedback.” - Paddy Corry, Why Perfect is the Enemy of Good

Maybe twenty years ago, we’d be happy to settle for delivering something every Sprint we can potentially release, but nowadays, ‘Done’ is just the beginning. It’s table stakes nowadays. The hard part isn’t delivering something anymore—the difficult part is creating something that makes a difference.

Of course, you may be working at a company that struggles to deliver anything, then by all means, first focus on improving your ability to churn out features. Concentrate on leveling up your ability to get things to ‘Done’ every Sprint. That’s the sensible thing to do. If you can’t deliver anything proficiently, improve your ability to deliver first, as then you’ll have much quicker feedback loops going on.

However, for everyone else, ‘Done’ won’t cut it, just like publishing this article isn’t good enough either. The proof of the pudding is in the eating: will my article help teams to get better at doing Sprint Reviews and improve their ability to deliver value? That’s what I care about, not the fact I’ve written something.

That’s the important thing I’ll be wondering and worrying about. Shipping this Sprint Review guide feels excellent, but if I discover something that can be improved, I’ll happily update this guide because ‘Done’ is just the beginning.