MoSCoW Method

From Wikipedia, the free encyclopedia

For other uses, see Moscow (disambiguation).

MoSCoW is a method that is used in business and particularly in software development to get an understanding with the customer on the importance they place on the delivery of each requirement. It originated as part of the Dynamic Systems Development Method. Sometimes called a MoSCoW list or a MOSCOW Analysis. MoSCoW stands for:

  • M - MUST have this.
  • S - SHOULD have this if at all possible.
  • C - COULD have this if it does not affect anything else.
  • W - WON'T have this time but WOULD like in the future.

The o's in MoSCoW are added to make the word pronounceable, and are often left lower case to indicate that they don't stand for anything.

Couple of points:

  1. MoSCoW was first coined/developed by Dai Clegg of Oracle UK in 1994.[1][2] He gave DSDM the IPR when DSDM needed a suitable RAD prioritisation technique.
  2. It is not only functional requirements that are MoSCoWed - it is all requirements

Contents

[edit] Explanation

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.

[edit] Must Have

Anything labelled as "MUST" has to be included in the project delivery timebox in order for it to be a success. If even one "MUST" item is not included, the project delivery is considered a failure. "MUST" is also an acronym for the Minimum Usable SubseT.

[edit] Should Have

While not critical to the success of the project delivery, "SHOULD" items are nearly as important and should be included if it is at all possible. "SHOULD" items are often as important as MUST items, however "SHOULD" items have workarounds allowing another way of satisfying the requirement.

[edit] Could Have

"COULD" items are less critical and often seen as "nice to have". A few easily built Coulds in a delivery can increase customer satisfaction for little development cost.

[edit] Won't Have (this time around)

"WON'T" items are either the least-critical or lowest-payback items. As a result, "WON'T" items are not planned into the schedule for the current project iteration. "WON'T" items are either dropped or reconsidered for reprioritization in later project increments. 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.

All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver in all the M, S and C categories but the S and Cs will be the first to go if the delivery timescale looks threatened.

[edit] Criticism

Some feel that classifying a requirement as "nice to have" makes it no longer a requirement, but more of a nicety. Therefore it no longer fits the definition of a "requirement" and thus has no place in a "Requirements" Document.

Response #1 Since the priority of requirements is fuzzy (and even varies over time) it is quite appropriate to consider "nice to have" items to still be "requirements". A "nice to have" item is generally one that has some return/payback but isn't part of the "minimum usable subset" required to deliver the product.

Response #2 Stakeholders in a new computer system will often come up with a Wish list (an alternative definition for the W) of every thing they can think might possibly be of use. To implement the whole wish list would be wasteful in time and money. MoSCoW is a way to work with that list so that a compromise is reached between what is most useful and can be built in a short timescale of 3 to 6 months and what can be put off to a future development cycle.

Response #3 Iterative development can also lead to re-prioritisation which can sometimes convert nice-to-have-s into should-haves.

Response #4 The only way to determine whether "nice to have" items have a place in a requirements document is to define the purpose of that document, and not be fooled by the common English definition of a requirement as "something required or obligatory" (quoted from Wiktionary:requirement).

Response #5 In defence of the W: many stakeholders contribute requirements that exceed the scope of a project; cannot be delivered in the initial implementation; or that the project board consider frivolous in budgetary terms. It is the Business Analyst's role to analyse these and work with the project's sponsor to determine what can be funded. It can damage stakeholder engagement if such requirements are subsequently excluded from published documents, as it can appear as if they have just not been captured, so it is better to retain them and classify them as 'W'.

[edit] Sources

[edit] References

  1. ^ Clegg, Dai; Barker, Richard (2004-11-09). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0201624328. 
  2. ^ Tierstein, L.M. (1997). "Managing a Designer/2000 Project" (PDF) in New York Oracle User Group. Fall '97. Retrieved on 2008-05-31. 
Languages