Serious Scrum
Published in

Serious Scrum

Showing all features at the Sprint Review should be like having mustard after the hot dog

Stop milking every feature you’ve completed at the Sprint Review

You might be puzzled because I’m talking about mustard and hotdogs 🌭 in relation to the Sprint Review. Don’t worry, I promise to get back to this later and explain everything.

A typical pattern I’ve observed at the Sprint Review is that Scrum Teams demonstrate every single feature they’ve built. No exceptions.

Photo by cottonbro

As a result, I’ve seen many Sprint Reviews deteriorate to a pissing contest — which team did a better job and churned out more features?

The Sprint Review becomes a feature demonstration snoozefest because nobody wants to draw the shortest straw in the feature delivery success theater.

Why do Scrum Teams feel the need to show every feature they’ve delivered?

Why should we try to get into a situation where this is no longer necessary?

What are common anti-patterns that hide beneath the surface when teams are busy milking every feature they’ve completed?

Let’s start by answering the first question.

Why do Scrum Teams feel the need to show every feature they’ve delivered?

Many Scrum Teams operate in companies with a Feature Factory mindset. Delivering more features is always better. As a result, every feature is seen as a success to be celebrated and treated as such. 👏*Clap* *Clap* *Clap* 👏 yay more features 🚀!

To make matters worse, stakeholders punish Scrum Teams when they fail to deliver all features as planned. Therefore it is important to appear busy and show you’re working hard at the Sprint Review. This way, even if you deliver less than expected, you might not be reprimanded.

In short, feature delivery theater at the Sprint Review often isn’t the fault of Scrum Teams but a result of the beliefs that are present in their environment. A consequence of higher velocity = more features = more value = always better.

In such an environment, Scrum Teams are expected to churn out features regularly and the motto is ‘build and forget.’ If you already know it’s valuable from the start, why bother looking back and reflecting? Don’t waste your time and get started on that next feature already!

Now it’s clear why Scrum Teams feel the need to show every feature they’ve delivered. Let’s talk about why we should aim to make this unnecessary.

Why should we try to move away from showing all features at the Sprint Review?

The purpose of the Sprint Review is to inspect and adapt your Product Backlog based on feedback. This means using feedback and what you’ve learned to decide with stakeholders what you will be working on next.

But before you can do that, you need to have transparency — to be sure you are making a decision based on reliable information.

What’s more reliable: a stakeholder giving feedback on something they see for the first time at the Sprint Review or having actual data and feedback from customers who use your product? It’s a no-brainer.

You should try to work towards a situation where your feature is already live before the Sprint Review. There should be no need to show your feature to stakeholders, as everyone already has seen it before the Sprint Review. If their input is necessary, they’ve already provided it.

Everybody is collaborating to make short feedback loops possible. We want to ensure a quick time-to-market to collect feedback and analyze data from users to improve and polish it further — or even kill the feature if that’s wisest.

Real feedback is what you should be aiming to show at the Sprint Review, not a stakeholder trying to imagine what the customer would be thinking. The starting point of your discussions should rooted in data and evidence. That’s information with a higher degree of confidence you can use to help decide what you should be working on next.

Of course, collecting sufficient data takes time. Probably by the time the Sprint Review happens you won’t have sufficient data to draw any meaningful conclusions. That’s yet another reason why it should be live sooner rather than later.

You should regularly revisit features at the Sprint Review to review current evidence on how it’s performing. As I’ve written before, ‘Stop suffering from goldfish memory at the Sprint Review’. The Product Increment isn’t the cherry you’ve just added on top in the last Sprint. It’s the whole cake with the cherry on top.

Instead of talking about the mustard, look at the hot dog sales

Showing a feature at Sprint Review should be as the Dutch saying goes: “Mosterd na de maaltijd,” translated as “Mustard after the meal.” After you’ve eaten your hot dog, you no longer need mustard.

Your feature should already be live before the Sprint Review, and instead of showing how it works, you should be showing how it is received and performing. Everybody should already know how it works before it goes live.

You shouldn’t delay market feedback for a Scrum event. You should push for faster feedback and shorter feedback loops. You can always polish and tweak the product afterward.

Next time you have a Sprint Review, instead of giving a demonstration of every feature you’ve delivered, ask yourself what you’re trying to achieve. Are you doing it because you are expecting valuable feedback? Or are you simply doing it to keep up appearances to prove you’re working hard?

Just listing what you’ve delivered as bullet points on a slide can be good enough. If you have learnings and new information, discuss that. And try to find a way of working that the Sprint Review isn’t the first time people see the feature in action. And even better: that it’s already live in production and you can show them how it’s doing.

Having features live in production will make your life easier. You’ll be talking about something tangible instead of having opinions about how something potentially could be performing once unleashed to the real world.

Expect every feature you’ve built to suck until you can hand over evidence to prove otherwise.

Remember this: your effort only shows to the extent it makes a difference for the customer.

Your customer doesn’t care or notice about how much effort you put in a feature, unless that effort makes a difference for them.

That’s what you should be trying to find out every Sprint.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store