MoSCoW Prioritization Method: Must, Should, Could, Won't

The MoSCoW prioritization method sorts a list of work into four buckets: must have, should have, could have, and won't have this time. Teams use it to agree what a project or release will actually deliver when there is more demand than there is time to deliver it. The value is not the four labels. It is the forced conversation about the won't-have list, which is the part most teams skip and the only part that protects a deadline.

MoSCoW came out of DSDM, an agile delivery framework, and it is built for time-boxed work: a fixed date, a fixed team, and a scope that has to flex. That origin matters, because the method only does its job when the deadline is real. Drop it onto a project with no fixed date and every item quietly becomes a must have.

What does MoSCoW stand for?

MoSCoW stands for Must have, Should have, Could have, and Won't have this time. It is a prioritization technique that groups requirements or features into four commitment levels rather than ranking them one by one. The capital letters carry the meaning; the two lowercase o's exist only so the word can be said out loud.

What is the MoSCoW prioritization method?

The MoSCoW method is a way to reach a shared decision about scope under a deadline. Instead of asking "how important is this feature" and getting the answer "very" from every stakeholder, it asks a harder question: which of these can we survive without, this time. That reframing is the whole trick. It converts a popularity contest into a set of survivable trade-offs.

Must have

A must have is something the release cannot go live without. The honest test is brutal: if you shipped without it, would the release be unusable, unsafe, illegal, or pointless. Regulatory requirements, core transactions, and anything that makes the rest of the release worthless belong here. Most teams over-populate this bucket, and an over-populated must-have list is the single most common way MoSCoW fails, because it leaves nothing to trade when the schedule tightens.

Should have

A should have is important and painful to omit, but the release survives without it because a workaround exists, even an ugly manual one. Should-haves are the difference between a release people tolerate and a release people like. Under schedule pressure they are the first negotiable layer: you deliver them if you can and defer them without breaking anything if you cannot.

Could have

A could have is genuinely wanted but low impact if left out. These are the items that get dropped when time runs short, and dropping them should cause no escalation and no drama. If dropping something in this bucket triggers a fight, it was misclassified and belongs one level up. Could-haves are your relief valve.

Won't have (this time)

A won't have is a thing you have consciously agreed not to do in this release, and it is the most valuable category in the method. The phrase "this time" matters: you are not killing the idea, you are timeboxing it out. Writing these down does two things. It stops the same requests reappearing every week, and it gives stakeholders a place to see their idea has been heard and parked rather than ignored. A MoSCoW exercise with an empty won't-have column has not actually prioritized anything.

What is the 60 percent rule in MoSCoW?

The 60 percent rule says your must-have items should consume no more than about 60 percent of the effort or capacity available in the time box. The remaining 40 percent, made up of should-haves and could-haves, is a deliberate buffer you can shed when estimates prove optimistic or something goes wrong. Because something always does.

The logic is simple. If must-haves eat 90 percent of capacity, you have no contingency, and the first slipped estimate turns a must-have into a missed deadline. Keeping must-haves near 60 percent means the project can absorb a bad week by dropping could-haves, which nobody will fight to keep, instead of dropping the launch date, which everybody will. This is also the honest gut-check on the must-have list: if you cannot get must-haves down to 60 percent, you are calling too many things essential.

How do you run a MoSCoW prioritization workshop?

Run it as a facilitated session with the people who own the scope and the people who own the delivery in the same room. The sequence that works:

1. Fix the time box first. State the date and the available capacity before anyone sees the list. MoSCoW is meaningless without a known constraint to prioritize against.
2. List the candidate items. Features, requirements, or work packages, at a consistent level of granularity. Mixing epics and tiny tasks in one list corrupts the exercise.
3. Start every item as a should have. Force each one to earn its way up to must or down to could. Starting from the middle stops the default drift to must have.
4. Test each must have out loud. Ask the survival question for every proposed must have. If the room cannot agree it is fatal to omit, it is not a must have.
5. Apply the 60 percent check. Sum the effort of the must-haves. If it is over 60 percent of capacity, send the weakest ones back down until it is not.
6. Name the won't-haves explicitly. Do not leave them off the list. Record them as deferred, so the decision is durable and visible.

The output is a scoped, agreed commitment for the time box, plus a documented deferral list. Feed both into the wider process in how to prioritize a project portfolio, because MoSCoW handles scope inside one initiative, not the choice between initiatives.

Is the MoSCoW method used in agile?

Yes. MoSCoW originated in DSDM, an agile framework, and it is widely used in agile delivery to prioritize a product backlog or the scope of a sprint or release. It fits agile naturally because agile fixes time and flexes scope, which is exactly the condition MoSCoW is built for. Teams tag backlog items with a MoSCoW category and pull must-haves first, treating should-haves and could-haves as the flex that absorbs velocity variance.

One caution in an agile context: MoSCoW categories are per release or per time box, not permanent labels. A could-have this sprint may be a must-have two sprints later once its dependencies land. Re-run the categorization each planning cycle rather than treating the tag as a fixed property of the item.

What is the difference between MoSCoW and RICE?

MoSCoW groups items into four commitment categories by consensus, while RICE produces a single numeric score (reach times impact times confidence, divided by effort) that ranks every item in strict order. MoSCoW is faster and better for agreeing scope under a deadline; RICE and other scoring models are more rigorous and better when you need a defensible ranked list and the differences between items are close enough to argue about.

They are not rivals so much as tools for different questions. Use MoSCoW to answer "what is in and out of this release." Use a numeric model to answer "in what order do we fund these competing projects." Many teams use both: MoSCoW to set the boundary, then a scoring model to sequence the must-haves and should-haves inside it. The full set of numeric approaches, including RICE, weighted scoring, and WSJF, is covered in the project scoring model guide, and the criteria those scores are built from are in project prioritization criteria.

MoSCoW method example

Here is a worked example for a customer portal release with a fixed launch date, illustrative rather than drawn from a specific engagement. The team estimated effort in story points and ran the 60 percent check against a 100-point capacity.

Must-haves total 60 of the 100 points, exactly at the rule. The 25 points of should-haves and could-haves are the buffer: if login runs over, the team drops themes, then chat, and still hits the date with a viable product. The mobile app is on the record as deferred, so it stops coming up in every status meeting.

What are the disadvantages of the MoSCoW method?

MoSCoW has three real weaknesses. First, it is subjective: without a firm test, "must have" becomes whatever the loudest stakeholder wants, and must-have inflation quietly kills the method. Second, it does not rank items within a bucket, so a list of twelve must-haves gives you no guidance on sequence when you cannot start them all at once. Third, it depends entirely on a fixed time box; applied to open-ended work with no deadline, there is no pressure forcing anything below must have, and the categories lose meaning.

Each weakness has a countermeasure. Enforce the survival test and the 60 percent rule to fight inflation. Layer a scoring model underneath to sequence within a bucket. And only reach for MoSCoW when there is a genuine constraint to prioritize against. Where the decision is which whole initiatives to fund rather than what scope to include, use the portfolio-level tools in project selection methods and the project prioritization matrix instead.