MoSCoW Method
From Wikipedia, the free 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.
The capital letters in MoSCoW stand 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 simply to make the word pronounceable, and are often left lower case to indicate that they don't stand for anything. While some suggest it should be MuSCoW (to more accurately reflect the words behind the acronym), MoSCoW is preferred as it is more easily remembered as the capital city of the Russian Federation.
MOSCOW is an acceptable variant, with the 'o's in upper case (see CamelCase for discussion)
[edit] Background
This use of MoSCoW was first developed by Dai Clegg of Oracle UK Consulting; in CASE Method Fast-Track: A RAD Approach [1][2]; 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 processes, such as DSDM and agile software development techniques.
[edit] Explanation
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 project 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, if new requirements are deemed more important). MUST can also be considered a backronym for the Minimum Usable SubseT.
- Should have
- SHOULD requirements are also critical to the success of the project delivery, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, however SHOULD requirements usually have workarounds allowing another way of satisfying the requirement until they can be included in a 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 project 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.
[edit] Sources
[edit] References
- ^ Clegg, Dai; Barker, Richard (2004-11-09). Case Method Fast-Track: A RAD Approach. Addison-Wesley. ISBN 978-0201624328.
- ^ Tierstein, L.M. (1997). "Managing a Designer/2000 Project" (PDF) in New York Oracle User Group. Fall '97. Retrieved on 2008-05-31.
