MoSCoW prioritization

By Gojko Adzic · Published 7 July 2026

MoSCoW Prioritization is a fast and rough prioritization technique that was popular from the mid-1990s to the early 2000s in the context of time-boxed development (particularly iterative delivery), and is still in use in project work based on the DSDM process.

• MoSCoW Framework
• Origins of MoSCoW Analysis
• Classification of Priorities
• Variants of the MoSCoW Model
• Applicability and Limitations

MoSCoW Framework

In the MoSCoW Framework, requirements or functions are grouped into four distinct categories, signifying certainty of delivery in the current phase of work:

• Must Have
• Should Have
• Could Have
• Won’t Have

The method name comes from the initial letters of the four categories, with lowercase o’s added to make the pronunciation easier.

There are several MoSCoW Technique Variants that assign slightly different meaning to these categories, but in general the first category includes functions that are certain to be included in a specified phase of delivery, the fourth includes functions that will not be included, and the middle two categories include functions or features where there is less certainty about including them in the current phase. The canonical grouping also explicitly includes assumptions about trading between the middle two categories as opportunities or circumstances change.

By grouping requirements into four general buckets, delivery teams can quickly agree with their stakeholders about the relative importance of work items and establish a policy for creating trade-offs to deal with unexpected changes during development.

The MoSCoW model is an example of Big Rocks Theory in practice, and a precursor to more modern roadmapping techniques such as the Now-Next-Later Roadmap.

The MoSCoW requirements analysis was introduced as part of CASE method development at Oracle in the early 1990s. Dai Clegg and Richard Barker documented the MoSCoW technique in CASE Method Fast-Track, in 1994, as “a way of classifying and prioritizing facilities for inclusion in an information system”, noting that it should be “used in timeboxed development where the scope may need to be redefined according to the rate of progress”.

Clegg and Barker argue that a key aspect of time-boxed development is that the “the project plan should allow for short meetings to review and re-assign priorities”, and explain the MoSCoW analysis approach as a way to quickly achieve an agreement with stakeholders on priorities for the current time-box.

… because there may not be time to complete all the requirements, it is necessary to prioritize them so that the team can spend their limited resources on delivering the features and functions that have the most value to the user. As the project proceeds, circumstances change. For example, a particular feature takes longer to implement than was expected, or a review of a development iteration reveals new features, more desirable than some already known. When this happens it will be necessary to reprioritize the outstanding work.

– Dai Clegg and Richard Barker, CASE Method Fast-Track

The MoSCoW model draws inspiration from Rapid Application Development (in general, Clegg and Barker present the Oracle CASE method as a RAD approach). In Rapid Application Development, published in 1991, James Martin provides a similar categorization, when defining the expected outputs of Joint Requirements Planning (JRP) workshops on page 149. In the category of “Details of possible system functions”, the output of a JRP workshop should include the “prioritization of the functions”, using three or more categories of priority. Martin suggests the following three categories:

• Which functions must be present in the first version of the system
• Which functions might be present in the first version if they can be built quickly
• Which functions ought to be saved for a subsequent version of the system

The MoSCoW model effectively splits the middle category into two separate buckets, and gives the method a memorable acronym. Martin’s RAD book predates Clegg and Barker’s book by three years.

A common misconception is that the MoSCoW model is related to RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels, from 1997. The RFC specifies a different categorization (Must, Should and May), and is best understood as an independent, parallel convention from the same era rather than an ancestor of the MoSCoW model.

Clegg and Barker recommend assigning requirements to one of the four MoSCoW categories as a result of value/cost analysis.

… describing and modifying scope relies on a twofold model of priority: the first aspect is the relative value; the second is the decision whether to include it or not, based on the weighting of value and its estimated cost to implement

– Dai Clegg and Richard Barker, CASE Method Fast-Track

They suggest that the value should be “subjectively ascribed by the stakeholder” and the cost should be “estimated by the project manager”.

According to Clegg and Barker, the MoSCoW prioritization is expected to be revisited and iteratively refined. It should happen as part of the design prototype review and at least once during build for an iterative development time-box, and the plan “should allow time for additional review meetings to be scheduled should the need arise”.

If circumstances change, items can move from one bucket to another. In particular, items from the “Should” bucket are sometimes expected to be “traded out”, and items from the “Could” bucket are expected to be sometimes “traded in” to the current time-box plan.

There are several overlapping and diverging variants of the MoSCoW technique. Clegg and Barker provide two different descriptions of the four categories in the original book.

The first definition is on page 27:

• Must: “This item will be included in the delivered project”
• Should: “The current project plan indicated that this item will be included. If circumstances alter, it may be traded out.”
• Could: “The current project plan indicates that this item will not be included. If circumstances alter it may be traded in.”
• Won’t: “This item will not be included in the delivered project.”

The second definition is on page 55:

• Must: “Without these, it is not worth delivering the project”,
• Should: “It is currently intended to deliver these as well”
• Could: “If time allows, some of these may be delivered”
• Won’t: “The project will not deliver these”

Notably, these two descriptions differ in the context of the third category. The first definition suggests the “Could” category will not be delivered, but is kind of a reserve backlog that needs to be monitored for changing priorities. The second definition implies that the “Could” category will be implemented if there is spare capacity left over.

The Business Analysis Body of Knowledge defines the four categories as a combination of the previous two definitions.

• Must: “Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.”
• Should: “Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.”
• Could: “Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.”
• Won’t: “Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future”

In DSDM Dynamic Systems Development Method, Jennifer Stapleton defined them differently, based on usefulness with “Won’t” renamed to “Want to have”.

• “Must have” for requirements that are fundamental to the system. Without them the system will be unworkable and useless.
• “Should have” for important requirements that will probably be classed as mandatory in less time-constrained development, but the system will be usable without them.
• “Could have” for requirements that can more easily be left out of the increment under current development
• “Want to have but will not have this time round” for those valuable requirements that can wait until later development phases take place.

The MoSCoW approach emerged as a way to plan (and re-plan) capacity assignment in the context of 1990s iterative delivery processes, when delivery phases of six months to a year were common. Lack of understanding of iterative delivery (which was then an emerging practice) and lack of trust between stakeholders and delivery teams caused by long delivery phases often resulted in most items being classified as “Must”, effectively defeating the purpose of categorization into four buckets. The DSDM (and later Agile Business Consortium) guide on MoSCoW prioritization recommends a limit of 60% capacity for Must items in a plan, and distributing 20% each to Should and Could categories, in order to leave a buffer for changes.

Most of the literature related to MoSCoW requirements prioritization applies the categorization on system features or functions, or functional requirements. Although there is nothing preventing the same method being applied to goals, outcomes or opportunities, in practice the MoSCoW method is mostly associated with functional decomposition and prioritization, making it difficult to prioritize by value. This is another reason why most items in practice end up labelled as Must. The Purpose Alignment Model breaks the “Must” category into several subcategories based on market differentiation and mission criticality, allowing teams to subdivide the Must category further. More modern approaches tend to prioritize outcomes and goals, and derive feature priority from impacted goals (for example, GIST model, Impact Mapping or Now-Next-Later Roadmap).

The MoSCoW model isn’t particularly important with shorter delivery phases typical for 2020s processes, as faster feedback and frequent replanning have significantly reduced the need to keep large buffers for delivery capacity months in advance. Teams using dynamic backlogs with more frequent reprioritization can simplify categorization, such as using Christmas prioritisation.

One of the key pitfalls of the MoSCoW approach is that in practical use organizations tended to assign items into categories based on a single dimension (such as importance or necessity, typically assigned by stakeholders), not following the “twofold model of priority” recommended by Clegg and Barker. Methods such as ICE Score explicitly call for multi-factor prioritization to avoid that.