MoSCoW method

For other uses, see Moscow (disambiguation).

The MoSCoW method is a prioritization technique used in management, business analysis, project management, 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.

The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Would like but won't get), with the interstitial os added simply to make the word pronounceable. While the Os are often left lower case, to indicate that they do not stand for anything, the all-capitals MOSCOW is also used.

Background

This prioritization method was developed by Dai Clegg and first used extensively with the Dynamic Systems Development Method (DSDM).

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 a technique commonly used in agile software development approaches such as rapid application development (RAD) and DSDM.

Prioritization of MoSCoW requirements

All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to go if the delivery timescale looks threatened.

The plain English meaning of the prioritization categories has value in getting customers to better understand the impact of setting a priority, compared to alternatives like High, Medium and Low.

The categories are typically understood as:

Must have

Requirements labeled as MUST are critical to 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

Requirements labeled as SHOULD are important but not necessary for delivery in the current delivery timebox. While SHOULD requirements can be as important as MUST, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.

Could have

Requirements labeled as COULD are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.

Won't have

Requirements labeled as WON'T have been agreed by stakeholders as 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. (Note: occasionally the term Would like is substituted, to give a clearer understanding of this choice).

Criticism

Karl Wiegers and Joy Beatty offered the following criticism of the MoSCoW method in the area of Software Development:

"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."

External links

• 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.