User:REPedia16vo/MoSCoW method

The MoSCoW method is a prioritization technique used 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. It is used in management, business analysis, project management, requirements engineering, and software development The method is mainly used to quickly and easily categorize many requirements without specifying much detail.

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, where interstitial Os are added to make the word pronounceable.

Background
The MoSCoW prioritization method was developed by Dai Clegg, a specialist in data modelling who was working as a consultant at Oracle , in 1994 for use in rapid application development (RAD). It was first used extensively with the dynamic systems development method (DSDM) from 2002. Clegg designed the framework to help his team prioritize tasks during development work on product releases.

The method is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements. Moreover, it is commonly used in agile software development approaches such as Scrum, rapid application development (RAD), and DSDM.

Prioritizing requirements using MoSCoW
Eliciting requirements is important. A requirement is defined as:

1. A need perceived by a stakeholder.

2. A capability or property that a system shall have.

3. A documented representation of a need, capability, or property.

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. DSDM advises that, in general, no more than 60% of the requirements should be assigned with Must have, and typically 20% of the requirements should be allocated to Could have. Going above 60% Must have requirements poses a risk to the predictability and success of a project, unless the criteria of a well-established team, minimal external risks, a well-understood approach, and accurate estimates are met.

Because the prioritization categories use natural language, it is easy for customers to better understand the impact of setting a priority, compared to alternatives like High, Medium, and Low. In addition, such alternative classifications that include a middle option, like "medium", can lead to uncertainty or a lack of clear decision-making.

MoSCoW categories
The categories are typically understood as:


 * Must have
 * Requirements labelled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must have, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered an acronym for the Minimum Usable Subset.


 * Should have
 * Requirements labelled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, 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 labelled as Could have are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.


 * Won't have (this time)
 * Requirements labelled as Won't have, have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox.

Variants
Sometimes W is used to mean wish (or would), i.e. still possible but unlikely to be included (and less likely than could). This is then distinguished from X for excluded for items that are explicitly not included. Occasionally the term Would like to have is used; however, that usage is incorrect, as this last priority is clearly stating something is outside the scope of delivery. The BCS in edition 3 & 4 of the Business Analysis Book describes 'W' as 'Want to have but not this time around'.

The MoSCoW method is sometimes described as using an ordinal scale to group the requirements into hierarchical scales, while other times being described as using a nominal scale because it classifies requirements in different priority groups.

Usage of MoSCoW method
Since the MoSCoW method is easy to apply, it is used across a variety of business disciplines. Because of the nature of the method, allowing teams to include multiple representatives from the organization, and the natural language used in the categories, the method is very generally applicable. Some fields have some extra steps or degrees of detail added to them. Those are elaborated upon in the following sections.

Requirements engineering
One field in which MoSCoW is often used for requirements prioritization is the field of requirements engineering. The MoSCoW method can be used for requirements elicitation during, for instance, requirements interviews *link to future RI page*. The MoSCoW prioritization method is best used in the early stages of projects, as requirements are usually not specified in a great degree of detail yet. When stakeholders have a greater understanding of the system and its requirements, it may be better to use other methods such as Cumulative Voting(also known as the Hundred Dollar Method) or Analytic Hierarchy Process. This also applies when more detailed goals have been discovered, and more information on the categories Should have and Must have is needed. Adding the Hundred Dollar Method at this time gives more detailed information about the relative value while consuming more time.

New product development
Another, more specific, scenario in which MoSCoW can be applied is in new product development. Particularly for those following agile software development approaches, there is always more to do than there is time or funding to permit (hence the need for prioritization). For example, should a team have too many potential epics (i.e., high-level stories) 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 (or MVP) 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 software features (or stories, if that is the subset of epics in their organization) are Must have, Should have, and so on; the minimum marketable features (or MMF) 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.

Below is a table showing example requirements for building a website where users can log in, categorized using MoSCoW (side-note: this is only an example, only the user actor is presented and the user stories and assigned categories are dependent on the context in which the product is created).

Advantages
The MoSCoW method has some advantages. It is highly ranked in terms of simplicity and time criteria, meaning it is easy and fast to apply. Moreover, because of its ease and clarity, the method generates a fair amount of confidence and consistency when applied, while being able to handle large numbers of alternatives. Additionally, the low complexity enables many types of stakeholders to partake in the categorization of requirements, including stakeholders that do not have experience with prioritization techniques. Therefore, the MoSCoW method is considered to be an appropriate method to negotiate and reach agreements with stakeholders while setting priorities at different levels of the implementation phase of a product. The MosCoW method also allows users to allocate a certain percentage of resources to each of the four categories, which helps in managing resources efficiently and in analyzing productivity in an optimized way.

Criticism
However, there is some criticism of the MoSCoW method. While the method helps understand customer needs, the method has difficulty of distinguishing the terms Must have and Should have, as they both express a customer preference or desire. Meaning there is a lack of rationale around how to rank competing requirements: why something is a must rather than a should. Another problem with the MoSCoW method, is that it does not give much insight in the different categories. It gives every requirement in a category equal priority; without information on the magnitude of preference. This is also apparent in the example table above, where the priority of users being able to log in is just as important as users being able to change account details, while these two requirements are very different in implementation. Moreover, there is ambiguity over timing, especially on the Won't have category: whether it is not in this release or not ever. Lastly, there is potential for political focus on building new software features over technical improvements (such as refactoring).

Other methods
Other methods used for product prioritization include:


 * RICE scoring model
 * PriX method prioritization method
 * Story mapping prioritization method
 * Value vs. effort prioritization method
 * Kano model prioritization method
 * Opportunity scoring prioritization method
 * The product tree prioritization method
 * Cost of delay prioritization method
 * Buy a feature prioritization method
 * Cumulative Voting (Hundred Dollar Method)
 * Wiegers prioritization *link to future Wiegers page*