MoSCoW Method

What the MoSCoW Method Is

The MoSCoW method is a prioritization framework that sorts tasks, features, or requirements into four categories: Must have, Should have, Could have, and Won’t have (this time). The capitalized letters in MoSCoW stand for these four categories, with the lowercase o’s added to make the acronym pronounceable.

The method was developed by Dai Clegg in 1994 while working at Oracle and later adopted as a core technique in the Dynamic Systems Development Method (DSDM), an Agile project delivery framework. It is now used widely outside of DSDM for any situation where a group needs to agree on what is in scope and what is not.

The Four Categories

Must have. Requirements or tasks that are non negotiable. Without them, the project fails, the sprint delivers no value, or the product cannot ship. Must haves typically represent 60% or less of total scope. If everything is a Must have, the framework is not being used correctly.

Should have. Important items that are not critical for this delivery. They add significant value and should be included if time and resources allow. If a Should have gets cut, the delivery still works but is less complete. Should haves typically represent 20% of scope.

Could have. Desirable items that have a smaller impact than Should haves. They are the first to be dropped when time or budget runs short. Could haves give teams a built in buffer: if the sprint finishes ahead of schedule, pull in a Could have. Typically 20% of scope.

Won’t have (this time). Items that are explicitly out of scope for this delivery cycle. The “this time” qualifier is important. These items are not rejected permanently. They are acknowledged, recorded, and deferred to a future cycle. This category prevents scope creep by giving stakeholders a place to park their requests without losing them.

How to Run a MoSCoW Session

Start with a complete list of tasks, features, or requirements. Gather the decision makers (product owner, project manager, key stakeholders). Review each item and assign it to one of the four categories through discussion and consensus.

The most productive sessions follow two rules. First, Must haves cannot exceed 60% of total capacity. This forces the group to make real trade offs instead of labeling everything as critical. Second, every item must land in one category. “We will decide later” is not an option. Ambiguity defeats the purpose of the exercise.

Time box the session. For a list of 20 to 30 items, 60 to 90 minutes is typical. For larger backlogs, pre sort into rough categories before the meeting and use the session to resolve disagreements on borderline items.

When to Use MoSCoW

MoSCoW works best when multiple stakeholders need to agree on scope. Common use cases include sprint planning (which user stories make this sprint?), release planning (which features ship in v1 vs. v2?), project scoping (what is in the contract vs. what is a future phase?), and budget allocation (which initiatives get funding this quarter?).

The method is fast to learn and fast to apply. It does not require scoring, weighting, or mathematical frameworks. This makes it accessible to non technical stakeholders who might struggle with weighted scoring models.

When MoSCoW Does Not Work

MoSCoW struggles when the decision maker is a single person with clear authority. If one person decides priorities, a simple ranked list is faster than a group categorization exercise.

It also breaks down when stakeholders cannot agree on what counts as a Must have. If every stakeholder insists their items are Must haves, the 60% rule gets violated and the exercise produces a list that looks like it was not prioritized at all. In these cases, a facilitator who can enforce the capacity constraint is essential.

MoSCoW does not provide relative priority within categories. All Must haves are treated as equally critical. If you need to know which Must have to work on first, you need a second prioritization step within the Must have group (a simple ranked list or time based sequencing).