MoSCoW method
The MoSCoW method is a prioritization technique. It is used in software development, management, business analysis, and project management to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is 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:
M - Must have,
S - Should have,
C - Could have,
W - Won't have.
The interstitial Os are added to make the word pronounceable. While the Os are usually in 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 in 1994 for use in rapid application development. It was first used extensively with the dynamic systems development method from 2002.MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements, and is commonly used in agile software development approaches such as Scrum, rapid application development, and DSDM.
Prioritization of requirements
All requirements are important, however to deliver the greatest and most immediate business benefits early the requirements must be prioritized. 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 be removed 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
; Should have
; Could have
; Won't have
Variants
Sometimes W is used to mean wish, i.e. still possible but unlikely to be included. This is then distinguished from X for excluded for items which are explicitly not included. Would is used to indicate features that are not required now, but should be considered in architectural terms during the design as future expansion opportunities - this avoids the risk of dead-end designs that would inhibit a particular feature being offered in the future.Use in new product development
In new product development, particularly those following agile software development approaches, there is always more to do than there is time or funding to permit.For example, should a team have too many potential epics for the next release of their product, they could use the MoSCoW method to select which epics are Must have, which Should have, and so on; the minimum viable product would be all those epics marked as Must have. Oftentimes, a team will find that, even after identifying their MVP, they have too much work for their expected capacity. In such cases, the team could then use the MoSCoW method to select which features are Must have, Should have, and so on; the minimum marketable features would be all those marked as Must have. If there is sufficient capacity after selecting the MVP or MMF, the team could then plan to include Should have and even Could have items too.
Criticism
Criticism of the MoSCoW method includes:- Does not help decide between multiple requirements within the same priority.
- Lack of rationale around how to rank competing requirements: why something is must rather than should.
- Ambiguity over timing, especially on the Won't have category: whether it is not in this release or not ever.
- Potential for political focus on building new features over technical improvements.