MoSCoW Method
Encyclopedia
MoSCoW is a prioritisation technique used in 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 prioritisation or MoSCoW analysis.
According to A Guide to the Business Analysis Body of Knowledge, version 2.0, section 6.1.5.2, the MoSCoW categories are as follows:
The o's in MoSCoW are added simply to make the word pronounceable, and are often left lower case to indicate that they don't stand for anything. MOSCOW is an acceptable variant, with the 'o's in upper case.
although he subsequently donated the Intellectual Property Rights 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 process
es, such as Dynamic Systems Development Method
(DSDM) and agile software development
techniques.
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
Should have
Could have
Won't have (but Would like)
Business Analysis
Business analysis is the discipline of identifying business needs and determining solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement, organizational change or strategic planning and policy development...
and software development
Software development
Software development is the development of a software product...
to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement
Requirements analysis
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...
- also known as MoSCoW prioritisation or MoSCoW analysis.
According to A Guide to the Business Analysis Body of Knowledge, version 2.0, section 6.1.5.2, 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.
The o's in MoSCoW are added simply to make the word pronounceable, and are often left lower case to indicate that they don't stand for anything. MOSCOW is an acceptable variant, with the 'o's in upper case.
Background
This use of MoSCoW was first developed by Dai Clegg of Oracle UK Consulting; in CASE Method Fast-Track: A RAD Approachalthough he subsequently donated the Intellectual Property Rights to the Dynamic Systems Development Method
Dynamic Systems Development Method
Dynamic systems development method is an agile project delivery framework, primarily used as a software development method. DSDM was originally based upon the rapid application development method. In 2007 DSDM became a generic approach to project management and solution delivery...
(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
Rapid application development
Rapid application development is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself...
(RAD) software development process
Software development process
A software development process, also known as a software development life cycle , is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle...
es, such as Dynamic Systems Development Method
Dynamic Systems Development Method
Dynamic systems development method is an agile project delivery framework, primarily used as a software development method. DSDM was originally based upon the rapid application development method. In 2007 DSDM became a generic approach to project management and solution delivery...
(DSDM) and agile software development
Agile software development
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...
techniques.
Prioritisation 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 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 backronymBackronymA backronym or bacronym is a phrase constructed purposely, such that an acronym can be formed to a specific desired word. Backronyms may be invented with serious or humorous intent, or may be a type of false or folk etymology....
for the Minimum Usable SubseT.
Should have
- SHOULD requirements are also critical to the success of the project, 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 (but Would like)
- WON'T 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 doesn't make them any less important.
- Sometimes this is described simply as "Would like to have" in the future, this however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.
See also
- 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.