Editing MoSCoW method

{{short description|Business analysis and software development technique}}
{{redirects here|MoSCoW||Moscow (disambiguation)}} 

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 [[Project stakeholder|stakeholders]] on the importance they place on the delivery of each [[Requirements analysis|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 ''O''s are added to make the word pronounceable. While the ''O''s are usually in lower-case to indicate that they do not stand for anything, the all-capitals ''MOSCOW'' is also used.{{Citation needed|reason=Does the original source describe MoSCoW vs MOSCOW?|date=July 2021}}

== Background ==

This prioritization method was developed by Dai Clegg<ref>{{cite book
 |last = Clegg
 |first = Dai
 |author2=Barker, Richard
 |title = Case Method Fast-Track: A RAD Approach
 |date = 1994
 |publisher = Addison-Wesley
 |isbn = 978-0-201-62432-8
}}</ref> in 1994 for use in [[rapid application development]] (RAD). It was first used extensively with the [[dynamic systems development method]] (DSDM) <ref>{{cite book
 |last = Bittner
 |first = Kurt
 |author2 = Spence, Ian
 |title = Use Case Modeling
 |date = 2002-08-30
 |publisher = Addison-Wesley Professional
 |isbn = 978-0-201-70913-1
 |url-access = registration
 |url = https://archive.org/details/usecasemodeling00kurt
 }}</ref> 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 (software development)|Scrum]], [[rapid application development]] (RAD), and [[Dynamic systems development method|DSDM]].{{cn|date=December 2024}}

== 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:<ref>{{cite book
 |title = A Guide to the Business Analysis Body of Knowledge|year = 2009|publisher = International Institute of Business Analysis|isbn = 978-0-9811292-1-1|edition = 2|chapter = MoSCoW Analysis (6.1.5.2)}}</ref>

; {{anchor|MUST}}{{anchor|must}} 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.

; {{anchor|SHOULD}}{{anchor|should}} 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.

; {{anchor|COULD}}{{anchor|could}} 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.

; {{anchor|WONT}}{{anchor|wont}} 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. (Note: 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 describe 'W' as 'Want to have but not this time around')

===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 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 (hence the need for prioritization). 

For example, should a team have too many potential epics (i.e., high-level [[User story|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''.<ref>{{Cite book|title=Agile Project Management for Government|last=Wernham|first=Brian|publisher=Maitland and Strong|year=2012|isbn=978-0957223400}}</ref> 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 (or stories, if that is the subset of epics in their organisation) are ''Must have'', ''Should have'', and so on; the [[Incremental funding methodology|minimum marketable features]] (or MMF) would be all those marked as ''Must have''.<ref>{{Cite book|title=Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage|last=Davis|first=Barbee|publisher=J. Ross Publishing|year=2012|isbn=978-1604270839|series=Project Management Professional Series}}</ref> 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.<ref>{{Cite book|title=Agile Development in the Real World|last=Cline|first=Alan|publisher=Apress|year=2015|isbn=978-1484216798}}</ref> 

== 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''.<ref name=":0" /><ref name=":1" />  
* Ambiguity over timing, especially on the ''Won't have'' category: whether it is not in this release or not ever.<ref name=":0">{{cite book|last1=Wiegers|first1=Karl|last2=Beatty|first2=Joy|title=Software Requirements|date=2013|publisher=Microsoft Press|location=Washington, USA|isbn=978-0-7356-7966-5|pages=320–321}}</ref> 
* Potential for political focus on building new features over technical improvements (such as refactoring).<ref name=":1">{{Cite news|url=http://www.hotpmo.com/blog/moscow-kano-prioritize|title=Moscow or Kano - how do you prioritize?|last=McIntyre|first=John|date=October 20, 2016|newspaper=HotPMO!|access-date=October 23, 2016}}</ref>

== Other methods ==
Other methods used for product prioritization include:

* [[Kano model | Kano model prioritization method]]

== References ==
{{reflist}}

== External links ==
*[http://www.ietf.org/rfc/rfc2119.txt 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.
* [https://www.researchgate.net/publication/220630837_Time_boxing_planning_buffered_moscow_rules 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.
*[https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html MoSCoW Prioritisation] Steps and tips for prioritisation following the DSDM MoSCoW rules.


{{DEFAULTSORT:MoSCoW Method}}
[[Category:Software project management]]
[[Category:Dynamic systems development method]]
[[Category:Computer jargon]]
[[Category:Software development philosophies]]