MoSCoW is a technique used in management, business analysis, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritization or MoSCoW analysis.
According to A Guide to the Business Analysis Body of Knowledge, version 2.0, section 220.127.116.11, the MoSCoW categories are as follows:
|M||MUST||Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.|
|S||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.|
|C||COULD||Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.|
|W||WON'T||Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Would" is substituted for "Won't" to give a clearer understanding of this choice).|
The "o"s in MoSCoW are added simply to make the word pronounceable, and are often left lower case to indicate that they do not stand for anything. MOSCOW is an acceptable variant, with the Os in upper case.
This use of MoSCoW was first developed by Dai Clegg of Oracle UK Consulting; in CASE Method Fast-Track: A RAD Approach  although he subsequently donated the intellectual property rights[clarification needed] to the Dynamic Systems Development Method (DSDM) Consortium.
MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements, and as such is seen as a core aspect of rapid application development (RAD) software development processes, such as Dynamic Systems Development Method (DSDM) and agile software development techniques.
Prioritization of MoSCoW requirements
All requirements are important, but they are prioritised to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the M, S and C requirements but the S and C requirements will be the first to go if the delivery timescale looks threatened.
The plain English meaning of the MoSCoW words has value in getting customers to understand what they are doing during prioritisation in a way that other ways of attaching priority, like high, medium and low, do not.
- Must have
- requirements labeled as MUST are critical to project success and have to be included in the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered a backronym for the Minimum Usable SubseT.
- Should have
- SHOULD requirements are important to project success, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, although SHOULD requirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery timebox.
- Could have
- requirements labeled as COULD are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.
- Won't have
- These requirements are either the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON'T requirements are not planned into the schedule for the delivery timebox. WON'T requirements are either dropped or reconsidered for inclusion in later timeboxes. This, however does not make them any less important.
Karl Wiegers and Joy Beatty offered the following criticism of the MoSCoW method:
"It [MoSCoW prioritisation] doesn't offer any rationale for making the decision about how to rate the priority of a given requirement compared to others. MoSCoW is ambiguous as to timing, particularly when it comes to the "Won't" rating. "Won't" could mean either "not in the next release" or "not ever". Such distinctions must be made clear so that all stakeholders share a common understanding of the implications of a particular priority rating. The three-level scale described previously [in the book], which relies on analysis of the two dimensions of importance and urgency, and focuses specifically on the forthcoming release or development timebox, is a crisper way to think about priorities. We don't recommend MoSCoW."
- A Guide to the Business Analysis Body of Knowledge. International Institute of Business Analysis. 2009. ISBN 978-0-9811292-1-1.
- Clegg, Dai; Barker, Richard (2004-11-09). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0-201-62432-8.
- Tierstein, L.M. (1997). Managing a Designer/2000 Project (PDF). New York Oracle User Group. Fall '97. Retrieved 2008-05-31.
- Wiegers, Karl; Beatty, Joy (2013). Software Requirements. Washington, USA: Microsoft Press. pp. 320–321. ISBN 978-0-7356-7966-5.
- RFC 2119 (Requirement Levels) This RFC defines requirement levels to be used in formal documentation. It is commonly used in contracts and other legal documentation. Noted here as the wording is similar but not necessarily the meaning.
- Buffered Moscow Rules This essay proposes the use of a modified set of Moscow rules that accomplish the objectives of prioritizing deliverables and providing a degree of assurance as a function of the uncertainty of the underlying estimates.
- MoSCoW Prioritisation Steps and tips for prioritisation following the Moscow rules.