Stop Wasting Your Time On MoSCoW Prioritization

Why MoSCoW Prioritization Sucks and Should Be 'Won't Have'

MoSCoW prioritization sounds powerful, but it usually sets you up for failure.

‘Must-have’, ‘Should-have’, ‘Could-have’ and ‘Won’t Have’. You’ve got these neat, little and definitive buckets at your disposal. You declare something as a Must-have and now everyone knows that it matters.

Every backlog item we put in a bucket gives us a feeling of clarity. Yet, that's the precise moment you can forget about discovering what really matters in your product.

You should be careful when someone says: "Let's do MoSCoW to figure out what really matters."

Because that’s precisely what you shouldn’t be doing.

Let’s dig in a real-world MoSCoW example.

MoSCoW to the MVP Rescue

Imagine the decision has been made to launch a new product. We’ve all been there. Everybody is excited and scared at the same time. How are we going to pull this off? What should be in there, and what shouldn’t be in there.

Somehow, we end up with a list of all the features that should be part of the product. At some point someone on the team asks: “What’s the scope of the MVP?”.

The stars are aligned and you get lucky. Nobody derails the whole meeting by asking the question: “What’s a MVP?”. Phew, we’ve dodged a bullet. Your lucky streak quickly comes to an end when someone asks the question: “Why don’t we use MoSCoW Prioritization to define the scope of the MVP?”

Big fucking mistake. That’s where it all goes down-hill.

We all go into a meeting room, and talk for hours to figure out the neat little bucket every feature should go into. You usually end up with something that looks as follows:

Because our eyes are bigger than our stomach, almost everything ends up in the Must-have bucket. We then happily start toiling away at our MVP must-have feature list.

The Lie of the Must-Have

Then, we start working on our MVP, and what happens is that for some reason it takes longer than expected. Surprise! Now you’re going to cut in scope again, and what was considered must-have suddenly no longer is a must-have.

The problem is, that the ‘Must-have’ was always a lie from the first time you used the label.

Repeat after me: features are never a Must-have, it’s what those features are supposed to make possible that’s a Must-have.

If something that was once Must-have, is no longer a Must-have, that means you had a poor understanding of the real Must-have.

Those neat little buckets, all they did is move the problem from one large list to a smaller list of work items. You’ve reduced the problem, but you didn’t fix the actual problem.

Prioritization isn’t about deciding what matters by labeling something you’ve decided to build as a Must-have, it’s about creating understanding of what matters. The difference is subtle, but the implications are huge.

When we label features as a Must-have we end up with Requirement Tunnel Vision. Our Must-haves are must-haves because we have designated them as such, while it’s actually never the feature that’s a Must-have but the real-world reason behind the feature that’s the Must-have.

Sounds fuzzy? Let’s make it concrete. You could label a feature to automatically export personal data as a Must-have. Why is it a Must-have? Well, we must be able to provide users with an export of their personal data when they request their data to comply with GDPR.

If you understand being able to export personal data is the requirement due to compliance with GDPR legislation, then you can talk about what’s really necessary. Is it really required to comply with GDPR? Would a manual export suffice? If someone sends an e-mail, how quickly could we provide a manual export?

This is just a hypothetical example, but the key point I want to hammer home: features are not a Must-have, but what they’re supposed to make possible is the Must-have.

When you have sufficient context and understanding, then you then can make the best decisions about what matters while taking into account your current understanding of the situation, e.g. delivery is taking longer than expected.

If you have buckets labeled as Must-have, Should-have, Could-have and Won’t Have, then all you have is a giant hot mess that obfuscates the real-world reasons why something is crucial.

How to Fix MoSCoW Fixed Scope Thinking

Here’s the list of ‘Must-have’ items we’ve ended up with. Can you answer the following questions:

• Why are these items a Must-have?

• Could we reframe the problem we’re trying to solve with these Must-haves to explore other solutions that might even be better?

• Do we understand what we’re trying to make possible with these Must-haves?

These are difficult questions to answer and they are easily obfuscated by putting stuff in a Must-have bucket.

By obsessing over MoSCoW prioritization, we’re often operating at the wrong level of the requirements puzzle.

We’re mostly talking about what we’ve documented, instead of what what we’ve documented is supposed to make possible.

We’re busy making a fatal mistake: we’re busy reverse engineering the scope of what we’re going to build from how our product will work.

Instead of starting with how your product works, start with what your product makes possible:
1. Who are the users of our product? What are their goals, and what are they trying to achieve? What are their jobs-to-be-done?
2. How does our product add value to these users and help to accomplish their goals?
3. When have we created sufficient value for our users that we can capture that as business value?

Must-haves don’t matter, it’s what those requirements make possible for our users in a way that works for the business that matters.

You’ve got a much better chance when you talk about what you’re product is supposed to help make possible and the different use-cases it should be able to support.

And when you understand the outcomes you’re trying to achieve, there’s no need to talk about MoSCoW anymore. Because it’s never the features are a Must-have.

As I’ve written before: delivering a feature is like telling a joke, it doesn’t matter unless it makes people laugh.

The laughter is the must-have, and the specific formulation of the joke is never the must-have.