With a lot of help from Wikipedia: MoSCoW is a prioritization 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 prioritization 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.
All requirements are important, but they are prioritized 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 prioritization in a way that other ways of attaching priority, like high, medium and low, do not.
I use this technique in creating marketing copy. It is an easy way to prioritize what needs to be said, how much space might be needed (which may assist you in your delivery method), and even make plans for follow-up and/or additional marketing copy to support the main message.
Must have requirements labeled as MUST have to be included in the current delivery. What has to be said in the message in order for it to be a success. If even one MUST requirement is not included, the copy would be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important).
Should have requirements are also critical to the success of the project, but are not necessary for delivery in the current delivery. This may be additional copy, follow up such as another direct mail piece, autoresponder, phone call, etc. SHOULD requirements are as important as MUST, although SHOULD requirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery.
Could have requirements labeled are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction if known. Used many times if filler material is needed or if space allows for little extra cost
Won’t have (but Would like) 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 process for delivery. WON’T requirements are either dropped or reconsidered for inclusion in later copy. Sometimes this is described simply as “Would like to have” in the future and the initial copy may assist in increasing the importance of these WON’T have. I still believe this is important to list these items, without doing this you may miss some opportunity during your evaluation process.
P.S. Some suggest it should be MuSCoW (to more accurately reflect the words behind the acronym),
Related Posts:
Receiving Better Response Rates thru Agile
Comments are closed.