MoSCoW Prioritization: Defining Must Haves

September 23, 2022

6 min read

MoSCoW Prioritization: Defining Must Haves

Like software requirements, not all chicken sandwich ingredients are of equal importance. MoSCoW can help you differentiate priorities.

MoSCoW Prioritization Method

MoSCoW is a clever mnemonic that aids in remembering four priority categorizations: Must Have, Should Have, Could Have, and Won’t Have (but Would Like to have in the future).

The Os are thrown in for shiggles, so we end up with a memorable mnemonic, “MoSCoW,” instead of the nonsense acronym MSCW.

A former boss of mine slyly referred to this as the Dr. Seuss prioritization method.

It took me a moment to make the connection, but as you can see from the video above, Dr. Seuss’ Green Eggs and Ham book uses could, should, and will not repetitively, hence the reference.

Dai Clegg is credited as the creator of this prioritization method. DSDM (Dynamic System Development Method), an agile project management approach, popularized the technique.

“On DSDM projects, requirements are sorted into four categories: Must Have, Should Have, Could Have, and Won’t Have. DSDM refers to this sorting as the MoSCoW rules.”
-Agile Estimation and Planning

Let’s start with an analogy to understand the different prioritization categories. The recent chicken sandwich wars got me thinking about what constitutes a chicken sandwich.

If we were going to jump into this war and expect to compete, there are some things that our sandwich really must have. The First would be chicken; you can’t argue that it’s a chicken sandwich if it doesn’t have chicken. The second mandatory ingredient is bread; we can’t meet the technical definition of a sandwich without bread.

Beyond that, we get into some things that our sandwich probably should have if we want to win the war. Without a sauce, our menu item will likely be a bit dry. All of the other sandwiches seem to have a sauce, so we should at least have mayo, if not a distinctive coating.

Then we get into some options that we could have. We’ll likely want more toppings other than just the sauce. We could have jalapeños, bacon, pickles, or a combination of toppings.

There are some things that we won’t have. We encourage out-of-the-box thinking, but no one wants anchovies on their chicken sandwich. We also won’t be making a salad (aka deconstructed sandwich) which we then try to pretend can compete with a sandwich. Maybe we would like to try options for fried vs. grilled chicken in the future, but we don’t want to commit to that without seeing how the basic sandwich does in some taste tests.

And this chicken sandwich turns out to be a pretty decent illustration of MoSCoW prioritization. Let’s dig deeper into each category and provide an example from a real-world software application.

Dorthy from Golden Girls motions toward her chin with I've had it up to here caption

Let’s say we’ve finally had it up to here with Jira’s idiosyncrasies. Forget dealing with all of its complexities and horrible UI; we’re going to build our own application. The ultimate project management tool (like a thousand people haven’t already tried this, huh?)

Must Have

The must-have category is reserved for functionality required to make the product viable. The concept of the minimally viable product gets a lot of flack from people that misunderstand it. Suffice it to say that there is always a subset of functionality that must exist before it makes to have a product release.

In the case of the chicken sandwich, this was the chicken and the bread.

In the case of the ultimate project management tool, these might be some must-have product features:

Ability to create and edit Product Backlog Items (PBI)
Ability to nest items into a hierarchy (think epics and features)
Ability to track the status of a PBI
Ability to allow multiple team members to access the application

In an ICP-APO course, I learned that some development teams limit a percentage of their backlog to the must-have category.

“When everything is a priority, nothing is a priority.”
-Karen Martin

Unsurprisingly, the experts don’t always agree on what this percentage should be. Agile Business Consortium’s DSDM Agile Project Framework Handbook recommends that no more than sixty percent of your overall Product Backlog should fall into this category.

According to Mike Cohn, DSDM projects limit this to 70%:

“No more than 70% of the planned effort for a project can be targeted at Must Have requirements. In this way, DSDM projects create a feature buffer equivalent to 30% of the duration of the project.”
-Agile Estimation and Planning

The primary point here is that all product backlog items can’t be must-haves. Agile teams should work with their Product Owner and relevant stakeholders to limit this scope. Limiting the number of user stories considered must-haves allows us to deliver something to our customers sooner, get feedback, and iterate on our product to meet customer needs.

Should Have

The should-have category is reserved for things that aren’t strictly required but should come close on the heels of the must-haves.

In the case of the chicken sandwich, this was the sauce.

For our awesome new application we’re building, the following are some examples of should-have features:

Git integration
Ability to customize statuses/workflows
Kanban board view
Analytics
Ability to comment on PBI to drive collaboration

Our application is useable without these features, but customer retention will be a struggle if we can’t compete with functionality that our users view as fundamental. We may not include these user stories in the MVP, but we will have them in a future release.

Could Have

The could-have category represents more minor tweaks that we could have if they’re not cost-prohibitive or if time constraints allow.

The various toppings were could haves for our chicken sandwich.

The following features are examples of potential could-haves for a work-tracking tool:

Ability to tag team members in comments
Ability to customize fields on the PBI
Email notifications for PBI changes
Ability to import issues from CSV file
Ability to define a product roadmap

These items are not crucial to the product’s success but would improve the value to our users.

Like must-haves, we should limit could-haves to a certain percentage of the overall Product Backlog. By balancing both the could-have and must-haves, you’re effectively managing the overall allocation.

Won’t Have

The won’t have category is reserved for things we’ve discussed implementing, but we’ve decided not to build - at least not right now.

Plate full of gross looking fried fish — I'm sure there are a few people in the world that enjoy anchovies, but I doubt there is a large fan base. Including them on a chicken sandwich would likely narrow our customer pool.

An example from our chicken sandwich endeavor was adding anchovies as a topping.

Functionality that might be suggested and decided against for our work management tool are:

Newsletter generator
Blinking status alerts
Permanent deletion of work items

Would Like

Every source I referenced while writing this article referred to the last category as Won’t Have, though I’d swear that I once read somewhere it was “Would Like.”

In her article Decrypting the MoSCoW Analysis, Janet Kuhn called the last category “WOULD LIKE (or want) TO HAVE NEXT TIME” so perhaps that explains why I thought it was ‘would like’ instead of ‘won’t have.’

Won’t have is more apparent than would like. Wouldn’t we like to have all the functionality?

Regardless of how you refer to the last category, it will include the things we’ve decided not to build because they don’t fit our vision of the product and things we’d still like to have, but only after we’ve implemented the higher prioritized items.

In the case of our chicken sandwich, the option to choose between grilled or crispy chicken is a would like.

Examples of would like features in a project management tool:

Conversions from other PM tools
Advanced query capabilities

MoSCoW Technique Criticisms

Mike Cohn has shared some criticisms of the MoSCoW technique. Though I agree with his sentiment that the categories are a bit unclear at first blush, we can fix this with some training.

Man looks at paper wad in his hand with 3 more on his desk — Not all ideas are great ideas. The ability to discern what functionality will provide the most customer value is the crux of determining priority.

In my experience, the issues encountered when prioritizing user stories are not because the categories are unclear; it’s more that the stakeholders cannot fathom that all of their great ideas aren’t all must-haves.

Cohn does offer an alternative prioritization scheme: needs, wants, and wishes. If the Dr. Seuss flavored prioritization technique in this article doesn’t work for your key stakeholders, you could experiment with an alternative to see if it provides more value for your development team.

Works Consulted

TLDR

Some people will be happy with a piece of grilled chicken on a bun. Others won’t be satisfied without mayo, bacon, and jalapeños.

Incremental delivery allows us to satisfy low-maintenance customers quickly while working toward delighting those that require more bells and whistles.

MoSCoW prioritization is a simple method to help stakeholders determine which requests are Must Have, Could Have, Should Have, or Won’t Have to ensure we’re implementing the high-value functionality first.