The MoSCoW prioritization method is a way to determine what a product or feature absolutely must have to launch, versus what it should have, could have or won’t have.
When using MoSCoW you must have a deadline, and allocate features to categories based on production criticality and business cost / reward.
It’s best used in 0-1 product builds, where you need to create an MVP.
That’s because it scopes the product to meet your constraints, rather than the time and resources to match the ideal product.
It helps manage non-technical stakeholders, and create clarity. It’s an ideal tool for when you have fixed time or resources and a top down directive or company goal.
It’s much less useful when working on established products. Use methods such as the RICE framework or other common backlog prioritization methods and matrices in those scenarios.
In this article we’re going to go through when to use MoSCoW, how it works, and who invented it, and then go through how to apply it step by step.
Let’s get into it now.
The MoSCoW prioritization method sorts features into categories to be delivered by deadline
What is the MoSCoW prioritization method
It’s a way of prioritizing features and components by criticality in order to deliver by a set date. It’s particularly useful for new products, new features or new businesses.
The idea is that you understand the most important things to build, in the right sequence to get something to market on time. Once it’s in the market, you can refine based on results, a live working product and customer feedback.
Example:
Team A has to launch a new product by Christmas. It’s August, and they estimate that to launch the product to competitor functionality, they need ~10 months to build.
They have ~5 months, or 50% of that time.
They use MoSCoW work through the minimum viable requirements (MVP), or must haves, to launch.
These represent 60% of the build effort, and will take up the majority of their time (3 months).
They also list out what else it might have for customers to have a positive user experience, and force rank the opportunities.
Knowing they have 1 month of build time they could allocate they select the top 5 of these as Should haves. This shortlist will take no more than 20% of the engineering days available of all the things proposed.
They pick the most critical items not included in Musts, especially those which will cause customer contacts and complaints.
In theory they will have 1 month left of engineering time. They select the next most critical things to build and mark them as Could Haves.
They then write down very explicitly what the product won’t have and share it with stakeholders to prevent misaligned expectations.
Finally, they negotiate time on the next quarter’s roadmap to deal with any tech debt and start shipping new Should haves, in order to be able to avoid bugs and iterate the MVP based on real user feedback.
They start building – with the goal of definitely completing must haves on time, and maybe completing should haves, with any time left over allocated to could haves.
To reflect this process of sorting and sequencing, the MoSCoW prioritization method is also sometimes called MoSCoW analysis.
It’s a planning technique where teams sign up to deliver Musts by a deadline, and have a backlog that can be tackled once Musts are complete:
- Must haves – 60% of what’s included for build
- Should haves – 20% of the team’s list, sequenced after Musts
- Could haves – another 20%, behind Shoulds
- Won’t haves – 0%, but itemized
The capitalized letters of MoSCoW stand for the core components of the prioritization method:
Project time in the MoSCoW prioritization method is defined as engineering days pre deadline
Must Haves should be thought of as what you absolutely need to get a product launched and into the wild.
Could Haves and Should Haves are what moves a product from functional to delightful.
Won’t Haves are documented exclusions.
Development of the MoSCoW method
MoSCoW was developed by Dai Clegg in 1994, when he was product everything (manager, marketing, evangelist) at Oracle, working on their CASE business tool and taking it from 0-1. The goal was to help his team prioritize their work during builds and still meet objectives.
It’s part of the Dynamic Systems Development Method (DSDM).
This is an agile methodology which maintains principles around incremental development and continuous user involvement, but sets time, build quality and investment constraints at the outset of any build.
When to use the MoSCoW method
Like every product framework, it’s a tool which needs to be applied in the right context.
It’s best in a 0-1 build, where you can clearly shape product requirements, have a tight deadline, and can work with others to get alignment.
Its strength is that it sets scope boundaries and is a process to communicate trade offs to stakeholders.
In these scenarios, product is often delivering an organizational vision: that of the CEO, founders, or C-suite.
The MoSCow prioritization method is least useful in contexts where you’re working on mature products.
This is especially the case when product backlogs are complex, span multiple features, and may include time sensitive customer requests or harmful bugs.
In these scenarios deadlines are less important than managing existing user bases, doing the right thing by the user, and building the right long term solution.
Alongside other frameworks
DSDM recommends setting a time box at every level of epic, story, task.
However the reality is that most teams find MoSCoW works best for top level prioritization, i.e. to sort features into delivery categories, such as Must, etc.
Many then bring in other frameworks or processes to triage within those categories. If you have a limited amount of time to execute on Shoulds, it’s useful to force rank your Shoulds according to some criteria.
Here’s some examples of how you can do this:
- RICE framework: Reach × Impact × Confidence ÷ Effort. Use MoSCoW to scope the release (what’s in or out), then use RICE to rank your Musts and Shoulds.
- Kano model: This classifies features by customer satisfaction impact (Basic, Performance, Delighters). You can use the customer satisfaction insight as a lens to prioritize features within MoSCoW categories.
- Value vs. Effort prioritization matrix: a visual ranking of initiatives weighing value against implementation cost. The weighted score is often recommended as a sense check on Must Have requirements within MoSCoW.
- WSJF (SAFe): effort of a job divided by the cost of delay to give a weighted score. Helps prioritize Should Haves & Could Haves.
How to use the MoSCoW prioritization method
Let’s walk through how to pull off a successful MoSCoW prioritization process by talking through how to
- Understand the phase you’re in: is it a deadline free innovation period, or a top down directive with a tight timeline
- Set a clear deadline: without a time constraint, MoSCoW is meaningless
- Create the long list: all the possible features that will later be sorted into categories
- Estimate Effort: work with your team to start understanding possible complexity and time investment for various features
- Define categories: create criteria for what constitutes a must, a should and so on
- Allocate features to buckets: running workshops to create alignment about what can and cannot be included by the deadline
Understand what phase you’re in
Project Management for PMs
Sometimes the job is to get a specific job done. It’s important to understand whether you’re in a:
- Blue Phase: working without time constraints on objectives as an autonomous unit. In this case MoSCoW isn’t the best tool.
- Red Phase: executing on a top down, strategic initiative, where there’s high conviction across the business that it will drive value. Use time boxed MoSCoW to ensure you deliver.
Common Red phase or delivery tasks include:
- Big bets: a new business model, new product, or pivoting the value proposition
- Legal or finance requirements: regulatory checks, pop ups or opt ins, cookie banners or a new payment provider
- Marketing requirements: a rebrand, implementing social sign in, a new CRM system
This is all things which have to get done, have known constraints, and which require working collaboratively across functions to both harvest knowledge and project manage the build to completion.
Set a clear deadline
Deadlines can be external (i.e. has to be done in time for xx regulatory requirement coming into force) or internal, in which case they should be based on a high level estimate of how long it will take.
It’s critical that the deadline:
- Is believable: both the CEO and your tech lead feel it’s a viable unit of time
- Is public and shared: it should be communicated clearly as a firm deadline, referred to in stand ups and sprints, and displayed on documents
- Is routinely referenced: so that teams understand that it is real and stands
It should be well understood by everyone at this point that the deadline stands, and how near or far away it is. If it’s tight, or involves technically complex builds, now is a good time to start surfacing this, and gaining pre-agreement from stakeholders that the project will be scoped to fit the time.
Once a deadline is fixed, you can move from asking your team how long something will take, to asking them what they can do within the time period.
Create the long list
The next thing you need is the long list from which will come your Must Haves, your Should Haves and so on. The best way to collect these is to run a series of workshops, both outside and inside the team.
The first key workshop is a kick off meeting with your internal team (engineers, designers) to articulate the main blocks of work to be done.
It’s good practice to prepare for this meeting by populating the problem definition section of a PRD, articulating the context, goals, whys and deadlines so that team members know why it matters and why they’re involved.
This meeting should already provide you with a feature list, but it should be re-run with external stakeholders as well, to ensure you capture everything. Especially when dealing with big bets or regulatory requirements, you’ll swiftly find that there’s multiple additional to-dos.
Having done this you should form your working squad. Ideally at this point you are able to draft a RACI.
The Hustle Badger RACI template
Estimate Effort
The next task is to break down requirements into discrete components of work, map dependencies and understand the effort to ship.
Ensuring that every component is “clean”, i.e. nice to haves aren’t hiding in among musts is critical at this point. As is effort estimation.
The 60/20/20 ratio isn’t based on feature count, but the percentage of time prior to deadline that the team has to build. Estimated effort, usually represented in engineering days, is a key input.
This ensures that when you start grouping features into category buckets, you can swiftly see if the task can be achieved within the deadline, or the deadline needs to move to be credible. It also helps spark effort vs reward conversations when debating Shoulds and Coulds.
The process also helps the engineering squad think through architectural complexity, dependencies and be able to start to articulate trade offs, i.e. technical debt vs micro services.
At this point you should already have a short list of must haves, since not every feature is optional when you’re shipping a product.
Define categories
In order to sort your features into categories, it’s good to have definitions of each category, and to socialize these so that everyone is on the same page when they consider or evaluate features.
Categories help clarify what will and will not be included and why
Definitions can vary depending on company context, but the key thing is that the definition is written down, socialized and clear.
Must have
Must is itself an acronym: it stands for Minimum Usable SubseT (MUST). MVP / Minimal Viable Product should be your north star.
Definition of an MVP (Techopedia)
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
The criteria for being a must are:
- Without x the project cannot be defined as delivered
- The solution is not viable without it
- Breaks the law or is unsafe without x
The DSDM handbook proposes 3 Must tests, to help frame the discussion:
- Cancel: A missing feature means you have to cancel the launch
- Workaround: A feature would be good, but there’s another way to deliver functionality, even if a painful manual one. If there is, it’s not a Must. It’s a Should or a Could.
- Delay: would you stop the release the night before launch to get this in? If you can launch without it, it’s not a must.
If everything looks like a Must, it’s usually a sign the work hasn’t been broken down enough.
Decompose the big items and separate out the real Musts from the herd.
Remember that you’re trying to push a concept into the wild and gather user feedback to refine it, vs a fully articulated vision.
Should have
Not an acronym, but defined as important, but not critical.
The criteria here are:
- Painful to omit, but the solution still works and can be delivered
- Other options to deliver exist, such as manual workarounds
The boundary between Could have and Should have can be unclear if you’re just working subjectively. It’s helpful to assign some hard metrics to force rank features which could be in either category: such as future revenue cost to the business of omitting x, or operational costs of manual workarounds, such as cost per incremental ticket.
A reminder that 60% of your list is Musts and 20% Shoulds.
All being well, you should be aiming to tick off at least some, if not all of your shoulds, so doing the work to understand the downstream impact of choices is not wasted effort.
Could have
Coulds are distinguished from Shoulds by degree of pain, defined as lost revenue and operational cost. Typically they are items where the return on product investment is lower than shoulds
The criteria here are:
- Desirable but unproven
- Lower impact than shoulds, in terms of cost, or known upside
Ideally you’ve force ranked many maybes, and understand engineering time to deliver, to be able to draw the boundary line based on time between Shoulds and Coulds.
Impact modelling your roadmap
Won’t have
This should be the majority of your list. It’s everything you have agreed won’t be delivered as part of this project within this time frame.
The power in documenting won’ts is to clearly communicate non-delivery, capture insights, and create clarity around the key items. Ideally log this and keep it centrally with a rationale of why items aren’t being included.
Worked example
A recurring subscription product
Must have: payment provider integration, and recurring payments enabled
Should have: ability for customers to cancel their subscription within the app
Could have: ability for customers to up or downgrade their subscription within the account
Won’t have: the ability for customers to pause and later reactivate their subscription
In the above example, the definitions are:
- Must have: basic functionality for the product to work and be able to prove concept
- Should have: expected customer functionality, manual intervention expected without it, but not needed immediately for launch
- Could have: a nice to have for customers that may well drive business value, could be done as a later step if product succeeds
- Won’t have: a very nice to have for customers, but mature product functionality
Based on your definitions, the next task is to do a rough sorting of your feature list, with must haves at the top, then should haves, then could haves. This is a core part of workshop preparation.
Allocate features to buckets
You’ll now have a short list of what has to be done, having worked with the engineering squad. But expectations of what the product will be will change, and no matter how good your initial scoping is, something else will have occurred to your stakeholders.
MoSCoW is as much about stakeholder alignment as it is about prioritization. The next step is to run a workshop that contains your key stakeholders, if necessary from the CEO down.
Baseline the workshop by
- Explaining the purpose: prioritizing work to be completed by deadline into must haves, should haves and could haves
- Sharing definitions: show how you’re currently defining categories, and thinking about must haves
- Walking through the current PRD: and confirming that the product or feature is properly articulated and described
Next, start the feature categorization process by
- Surfacing your existing feature list: and checking it’s complete
- Working with the team to identify must have features: use your engineering lead here to step in, explain estimates and explain why certain things have to be done
- Allowing stakeholders to surface known unknowns: it’s not unusual for critical items to come up at this point and have to be included and quantified; but
- Insist on guardrails: critical must haves have to be supported by some criteria, such as required functionality, or strong qualitative or quantitative data support
- Keeping a running tally: of what percentage of effort available prior to deadline has been allocated
- Surfacing dependencies: your stack will mean if you do one thing, you must do the other thing. If something is a must have, the other thing that has to be done is also a must have and has to be factored into the effort
- Managing the troops: respectfully insisting on category definitions, and ensuring shoulds and coulds go into the right buckets
- Reminding stakeholders of the deadline: the goal is to make the end product fit the time constraint, and discussing trade offs, compromises and possible next steps
Best practice is to start with everything on the Won’t Do list, and to expect that to remain the longest. Iterate category definitions and the deadline with stakeholders if required.
Stand firm on the 60/20/20 split of effort allocation between must haves, should haves, could haves. That’s there to ensure you can meet expectations.
It must be recognized within the workshop as a fundamental constraint, and part of the rules within which everyone must play. If the CEO really wants something included that lowers the probability of hitting deadline, the deadline has to move.
Example:
Benoît des Ligneris, a Senior PM at Shopify observes that the value of the MoSCoW prioritization method is that the process forces discussion about the essentials, versus perfectly allocated category lists.
In cases where there’s debate, it’s important to be very clear on who the ultimate decision maker is. Using an accountability framework like RAPID which defines who the ultimate ‘D’ is for big, one off decisions can assist here. The DECIDE framework is an alternative to RAPID, and does the same job.
At the end of the workshop, you should be left with a draft list of must haves, should haves, and could haves, with a long list of won’t haves.
Share these post workshops, along with the PRD, edited if need be, and give max 1-2 weeks for additional feedback. Ideally publish publicly and make sure the decisions are visible to all.
You will get push back and last minute panics, but stand firm on minor details and escalate any major trade offs to the end decision maker. Then lock the list, and prepare to build.
Common MoSCoW prioritization method mistakes
MoSCoW can fall down when it’s used without understanding what it is and is not.
There’s three common problems:
- Misunderstanding of Must: Any prioritization can deteriorate if requirements aren’t clear to all stakeholders. Must criteria has to be aligned and set out up front, and stuck to.
- Misunderstanding the method: Confusion about whether Musts, Shoulds, Coulds is a categorization of a product’s total possible feature set, or driven by a deadline.
- Misunderstanding of the boundary between Shoulds and Coulds: people often fixate on the naming of the categories, versus the sequence in which they will be built and the probability of them actually being delivered.
Misunderstanding of Must
MoSCoW comes with an out of the box definition of what constitutes a Must Have: can’t ship the project without this, but the reality is that must can be subjective for stakeholders.
As a PM you need to set or agree upfront objective criteria, such as ‘needs this to actually work onsite’ or ‘if it doesn’t have this we’re breaking the law’.
Ideally MoSCoW starts from an agreement that the goal is to launch an unproven, immature product, backed by a clear understanding of what’s possible within the site architecture, and required under law.
This needs to be shared with stakeholders as a baseline from which everyone will work. If that criteria flexes, it needs to be documented and clear.
Misunderstanding the method
A common misconception about MoSCoW is that it’s a categorization of future features, versus a documentation of what will be built within a defined timeframe.
“In practice with MoSCoW something is either done or it is not. So why pretend at the outset that MoSCoW is anything but binary? Why not just reduce it to MW – ‘Must Have, Won’t Have?’” – Scott Middleton
MoSCoW isn’t an open ended agile prioritization process. It’s actually meaningless without a deadline, as categorization is designed to sort features into time blocks to create project buffer.
A Monte Carlo simulation showed that by using the 60 / 20 / 20 splits on Musts, Shoulds, Coulds, teams can under-estimate Musts by 100% and still have a 98.9% probability of shipping on time.
That’s because Should haves and Would haves create a 40% buffer zone that allows the team to meet their goal.
The MoSCoW prioritization method is a way to build buffer to achieve MVP deadlines
Misunderstanding of the boundary between Should and Could
Let’s now deal with the final issue with MoSCoW, which is that a lot of people find that Must Have, and Won’t haves make sense as categories, but find the split between Should Haves and Could Haves unclear.
“There are a couple of things I dislike about the MoSCoW technique. First is that I can’t recall a project ever including any could-have features. A feature on the could-have list might as well be put on the Will-Not-Have list.” – Mike Cohn
This is all about buffer and deadlines. Shoulds are essentially the 20% of things you’d like on top of the Musts: since it’s likely that delivering Must will take longer than you think. When a build team commits to Shoulds, they’re usually signing up to try and deliver them by launch. Coulds are unlikely to make it.
The boundary line between Shoulds and Coulds ultimately comes down to the ROI on the work. Shoulds are features excluded from Musts, as they can be worked around, but where there’s significant pain in doing so: either in terms of lost revenue or cost.
Wrap up on the MoSCoW prioritization method
The MoSCoW prioritization method is a useful tool when you’re building MVPs in a tight time frame. But it can be used incorrectly, or constraints enforced too weakly.
It often falls down when
- It’s used on mature products: this is best for tight launches of new features and products
- Used as a one size fits all: it can work best when supported by other frameworks, such as RICE, Kano, Value / Effort and so on
- Deadlines aren’t considered: if there’s no deadline, you’re simply building the product people want to build
- Everything is must have: the most common tension when using MoSCoW, since it makes the process of attempting to agree trade offs meaningless
- The 60/20/20 split isn’t enforced: it’s there to help you meet deadlines, and if you don’t scope effort, or obey the splits, risk of failure goes up
- Workshops are run on gut feel: scoping effort, supporting conclusions with discovery and insight all helps get to a far better outcome
- It’s applied in a vacuum: collaboration and communication is the key to MoSCoW working well. Otherwise you’re just saying no in a different way.
On top of that, MoSCoW is ultimately inherently subjective and reflects the opinions of an internal team, rather than a customer view.
Try to surface the voice of the customer where possible, don’t skip discovery because it’s a top down ask, and try to share a research pack in advance of feature scoping meetings.
More Hustle Badger Resources
Templates
Articles
Courses
Other MoSCoW prioritization method Resources
FAQs about the MoSCoW prioritization method
What does MoSCoW stand for?
MoSCoW stands for Must have, Should have, Could have, and Won’t have. The capitalized letters spell out the four categories you sort features into.
What does MUST stand for in MoSCoW?
Must is itself an acronym: Minimum Usable SubseT. It’s the smallest set of features the product needs to launch and prove the concept. If the solution isn’t viable without it, or it breaks the law, it’s a Must.
Who invented the MoSCoW prioritization method?
Dai Clegg developed MoSCoW in 1994 while at Oracle, working on their CASE tool. It’s part of the Dynamic Systems Development Method (DSDM), an agile framework that fixes time, quality, and investment at the start of a build.
What is the 60/20/20 rule in MoSCoW?
It’s the recommended split of build effort: roughly 60% on Must haves, 20% on Should haves, and 20% on Could haves. The split is based on the percentage of time you have before the deadline, not the number of features. The 40% of Shoulds and Coulds acts as a buffer that protects your launch date.
What’s the difference between Should have and Could have?
Both are things you’d like but can work around, so the boundary comes down to the pain of leaving them out. A Should have is painful to omit, usually because of lost revenue or the cost of a manual workaround. A Could have is lower impact and less proven, and it’s the first thing to get cut when time runs short.
Can you use MoSCoW without a deadline?
No. MoSCoW is meaningless without a fixed deadline, because the categories exist to sort features into time blocks and create a delivery buffer. With no time constraint, you’re just building the product people want to build.
Is the MoSCoW prioritization method an agile technique?
Yes. MoSCoW comes from DSDM, an agile methodology built around incremental delivery and continuous user involvement. It works best for top level prioritization, sorting features into Must, Should, Could, and Won’t, with other frameworks like RICE or Kano used to rank items within those buckets.
What are the limitations of MoSCoW?
MoSCoW falls down on mature products, where managing an existing user base matters more than a launch date. It’s also inherently subjective and reflects an internal team’s view rather than the customer’s. The most common failure is everything becoming a Must have, which makes the whole trade-off exercise meaningless.
When should you not use MoSCoW?
Don’t use the MoSCoW prioritization method when you’re working on an established product with a complex backlog, time-sensitive customer requests, or harmful bugs. In those cases there’s no single hard deadline driving scope, so a continuous method like RICE or Kano will serve you better.
