MoSCoW

tool · management · organizing-schema

Prioritizes requirements as Must, Should, Could, or Won't have.

MoSCoW is a requirements-prioritization technique that classifies features or requirements into four categories: Must have (critical for the immediate delivery — the project fails without these); Should have (important but not vital — workarounds exist for the delivery); Could have (desirable but less important — included if time and resource permit); and Won't have this time (excluded from the current scope but acknowledged for future consideration). The 'o's are inserted for pronunciation. The technique was developed by Dai Clegg at Oracle in 1994 as part of the Dynamic Systems Development Method (DSDM) and has become a standard prioritization technique in agile, particularly within DSDM, but more broadly in project management, requirements engineering, and product management practice. The 'Won't have' explicitly named acknowledgment of de-scoped items is a distinctive contribution that distinguishes MoSCoW from purely rank-ordering techniques.

Originators

Dai Clegg (Oracle, within DSDM) high

Year / Decade

1994 high

Primary sources

DSDM Consortium. DSDM Agile Project Framework (multiple editions), Clegg, D. & Barker, R. (1994). Case Method Fast-Track: A RAD Approach high

Core components

Must have (critical for delivery)
Should have (important but not vital)
Could have (desirable, included if possible)
Won't have this time (excluded from current scope)
Categorical rather than rank-ordered prioritization
Time-boxed scope orientation
DSDM origin

Primary use case

Agile and iterative-development requirements prioritization; product backlog grooming; project-scope negotiation; teaching tool for distinguishing must-have from nice-to-have features.

Common criticisms

Tendency for everything to drift into Must have, defeating the prioritization purpose
categorical rather than rank-ordered, so doesn't differentiate within categories
doesn't address effort or value quantitatively (which RICE and ICE attempt)
'Should' and 'Could' boundaries are subjective and contested
doesn't surface trade-offs between equally-categorized items
can be gamed by stakeholders who lobby for higher categorization
works best when scope is genuinely time-boxed and Must-have list is constrained.

Lineage

Siblings: RICE Scoring, ICE Scoring, Eisenhower Matrix