Jump to content

User:REPedia16vo/MoSCoW method

From Wikipedia, the free encyclopedia
For other uses, see The Moscow rules and Moscow (disambiguation).

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.[1][2]

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

[edit]

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

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

Prioritizing requirements using MoSCoW

[edit]

Eliciting requirements is important. A requirement is defined as:[8]

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.[9]

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.[9]

MoSCoW categories

[edit]

The categories are typically understood as:[10]

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

[edit]

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[1], while other times being described as using a nominal scale because it classifies requirements in different priority groups.[11][12]

Usage of MoSCoW method

[edit]

Since the MoSCoW method is easy to apply, it is used across a variety of business disciplines.[13] Because of the nature of the method, allowing teams to include multiple representatives from the organization,[14] 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

[edit]

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.[1] 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.[12] 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.[1]

New product development

[edit]

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.[15] 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.[16] 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.[17]

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

Requirement MoSCoW
A As a user, I want to be able to register so that I have an account. Must
B As a user, I want to be able to log onto the web site. Must
C As a user, I want to be able to reset my password so that I can change the password in case I forget it. Should
D As a user, I want to be able to add Two-Factor Authentication for logging in so that there is an extra layer of security in which other people do not have access to sensitive personal data. Should
E As a user, I want to be able to change account details. Must
F As a user, I want to be able to send an email to the system requesting, so that I can change the account page. Could
G As a user, I want to make an automatic call when I click on a phone number on the web page so that I do not have to copy the phone number. Won't
H As a user, I want to be able to change the shown content when I am logged in, so that I have a personalized website. Could

Advantages

[edit]

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.[1][18] Moreover, because of its ease and clarity[2], the method generates a fair amount of confidence and consistency when applied, while being able to handle large numbers of alternatives.[1] 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.[1] 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.[19]

Criticism

[edit]

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.[18] Meaning there is a lack of rationale around how to rank competing requirements: why something is a must rather than a should.[20][21] 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.[1] 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.[20] Lastly, there is potential for political focus on building new software features over technical improvements (such as refactoring).[21]

Other methods

[edit]

Other methods used for product prioritization include:

References

[edit]
  1. ^ a b c d e f g h Hatton, Sarah, "Early Prioritisation of Goals", Advances in Conceptual Modeling – Foundations and Applications, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 235–244, doi:10.1007/978-3-540-76292-8_29, ISBN 978-3-540-76291-1
  2. ^ a b Department of Software Engineering University of Science and Technology Bannu, 28100 Pakistan; Ali Khan, Javed; Ur Rehman, Izaz; Hayat Khan, Yawar; Javed Khan, Iftikhar; Rashid, Salman (2015-11-08). "Comparison of Requirement Prioritization Techniques to Find Best Prioritization Technique". International Journal of Modern Education and Computer Science. 7 (11): 53–59. doi:10.5815/ijmecs.2015.11.06.{{cite journal}}: CS1 maint: numeric names: authors list (link)
  3. ^ Clegg, Dai; Barker, Richard (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0-201-62432-8.
  4. ^ Cunff, Anne-Laure Le (2021-08-18). "The MoSCoW method of prioritization". Ness Labs. Retrieved 2023-01-23.
  5. ^ Bittner, Kurt; Spence, Ian (2002-08-30). Use Case Modeling. Addison-Wesley Professional. ISBN 978-0-201-70913-1.
  6. ^ a b "MoSCoW Prioritization". www.productplan.com. Retrieved 2023-01-23.
  7. ^ "What Is Moscow Prioritization? Definition, How-to & FAQ". airfocus.com. Retrieved 2023-01-23.
  8. ^ Glinz, M. (2011). A glossary of requirements engineering terminology. Standard Glossary of the Certified Professional for Requirements Engineering (CPRE) Studies and Exam, Version, 1, 56.
  9. ^ a b "Chapter 10: MoSCoW Prioritisation". Retrieved 2023-01-11.
  10. ^ "MoSCoW Analysis (6.1.5.2)". A Guide to the Business Analysis Body of Knowledge (2 ed.). International Institute of Business Analysis. 2009. ISBN 978-0-9811292-1-1.
  11. ^ Hudaib, Amjad; Masadeh, Raja; Qasem, Mais; Alzaqebah, Abdullah (2018-01-15). "Requirements Prioritization Techniques Comparison". Modern Applied Science. 12 (2): 62. ISSN 1913-1844.
  12. ^ a b Vestola, M. (2010). A comparison of nine basic techniques for requirements prioritization. Helsinki University of Technology, 1-8.
  13. ^ "What is the MoSCoW Method?". Software Quality. Retrieved 2023-01-23.
  14. ^ "A Quick Guide to the MoSCoW Method Technique | Wrike". www.wrike.com. Retrieved 2023-01-23.
  15. ^ Wernham, Brian (2012). Agile Project Management for Government. Maitland and Strong. ISBN 978-0957223400.
  16. ^ Davis, Barbee (2012). Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage. Project Management Professional Series. J. Ross Publishing. ISBN 978-1604270839.
  17. ^ Cline, Alan (2015). Agile Development in the Real World. Apress. ISBN 978-1484216798.
  18. ^ a b Aljuhani, Abdulmajeed; Benedicenti, Luigi; Alshehri, Sultan (2017). "Ranking XP Prioritization Methods based on the ANP". International Journal of Advanced Computer Science and Applications. 8 (5). doi:10.14569/ijacsa.2017.080501. ISSN 2156-5570.
  19. ^ "What is the MoSCoW Method?". Software Quality. Retrieved 2023-01-13.
  20. ^ a b Wiegers, Karl; Beatty, Joy (2013). Software Requirements. Washington, USA: Microsoft Press. pp. 320–321. ISBN 978-0-7356-7966-5.
  21. ^ a b McIntyre, John (October 20, 2016). "Moscow or Kano - how do you prioritize?". HotPMO!. Retrieved October 23, 2016.
[edit]
  • 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 DSDM MoSCoW rules.
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:REPedia16vo/MoSCoW_method&oldid=1135427039"