MoSCoW

Origin & evolution

Dai Clegg developed MoSCoW while at Oracle in the early 1990s, creating it to support rapid application development work where fixed timeboxes meant you could not do everything and choices had to be made explicitly. He formalised it within DSDM (Dynamic Systems Development Method), a framework for time-boxed delivery that was codified by the DSDM Consortium in the mid-1990s. The Agile Business Consortium, which now stewards DSDM, maintains MoSCoW as a core technique in the framework handbook.

The method has since escaped its DSDM home and spread into product management, programme delivery, and sprint planning in organisations that have never used DSDM at all. In most modern usage it operates as a standalone prioritisation exercise applied to product backlogs, feature⭐FeatureProduct SpecificationA product capability or featureView reference → lists, or scope negotiations. The four letters spell MSCW, with the lowercase Os added purely to make the word pronounceable.

How it works in practice

The team assembles a list of requirements and assigns each one to exactly one bucket:

• Must Have items are non-negotiable. Without them the release🚢ReleaseProduct SpecificationA shipped version of the productView reference → is not viable, or a legal or safety obligation goes unmet. If a Must Have cannot be delivered, the release must be cancelled or the scope renegotiated.
• Should Have items are important and expected, but the delivery can still be considered a success without them. They are strong candidates for the next cycle.
• Could Have items are desirable but easily deferred. They get included if time and resource allow, and dropped first if they do not.
• Won't Have this time items are explicitly out of scope for the current window. The label matters: it signals a deliberate decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → and not a forgotten request.

A concrete example. A payments team building a new checkout flow designates three items as Must Have: card tokenisation, 3DS authentication, and an order-confirmation email. Smooth address autocomplete is Should Have. Saved card management is Could Have. A full loyalty-points dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → is Won't Have this time. The team can now timebox their sprint confident that the non-negotiable items take absolute precedence and that any overrun comes from Could Have items first.

The exercise works best when the whole delivery team participates, not just product management. Engineers often know which items are deceptively expensive and can argue a Could Have down to Won't Have before planning starts.

When to use it (and when not)

MoSCoW is well suited to any situation where scope must be agreed across multiple stakeholders🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference →, the delivery window is fixed, and trade-offs are inevitable. Kick-off workshops, sprint planning, release scoping, and scope-cut negotiations with clients are all natural homes for it.

It earns its keep less well when applied to a backlog of hundreds of items by a single person working alone: without the social friction of a group agreeing each assignment, every item drifts toward Must Have and the exercise loses its purpose. The technique also says nothing about sequencing within a bucket, so teams often need🫀NeedUserA user need, pain, desire, or constraintView reference → to follow it with a ranking method once the buckets are set. A common failure mode is treating Should Have as a polite name for Must Have: when the Must Have bucket fills up, scope creep moves in disguised as a downgrade. Discipline requires holding Must Have to no more than roughly sixty percent of available capacity so the team has genuine room to absorb the unexpected.

In the Unified Product Graph

MoSCoW is a table framework in the prioritisation category. All four buckets map onto the same entity type in the Unified Product Graph, because what varies between them is not the kind of thing but the priority attached to it:

• Must Have, Should Have, Could Have, and Won't Have all resolve to feature⭐FeatureProduct SpecificationA product capability or featureView reference → entities.

The Unified Product Graph models the distinction through the feature's priority property and its relationships; every item stays a feature⭐FeatureProduct SpecificationA product capability or featureView reference → and the priority field carries the MoSCoW band. A feature⭐FeatureProduct SpecificationA product capability or featureView reference → node carries a priority field and connects to the goals, epics📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference →, and releases it relates to. Sorting features by that priority field reproduces the MoSCoW table directly. The advantage is that a feature classified as Won't Have this time is not discarded: it remains in the graph, linked to the work it would deliver, and can be promoted to Should Have in the next planning cycle🗓️Planning CycleProduct SpecificationThe cadence axis of a plan: a dated interval a team plans in, be it a sprint, iteration, quarter, or program increment. cadence_kind classifies its granularity in methodology-neutral terms (period for a coarse container, iteration for an execution box, buffer for cooldown slack) while cadence_label keeps the team's own word for it. Cycles self-nest, so fine iterations sit inside a coarse period to form a granularity ladder. Objectives scope to a cycle and stories schedule into it by deliberate links, not containment: a story keeps its feature or epic parent.View reference → without being recreated from scratch.