|
|
|
|
|
Moscow MethodMoSCoW is term used in software development and comes from the dynamic systems development method. Using MoSCoW requirements for a software delivery can be prioritized by the customer. MoSCoW stands for: - M - MUST have this.
- S - SHOULD have this if at all possible.
- C - COULD have this if it does not effect 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. 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. Anything labeled 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. 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. "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 "WON'T" items are the least critical and are not planned into the schedule for the current project. "WON'T" items are either dropped or reconsidered for reprioritization in later project increments. This, however doesn't make them any less important. All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will try to deliver in all the M, S and C categories but the S and Cs will be the first to go if the delivey timescale looks threatened. Criticism Some feel that by classifying a requirement as "nice to have" it make it no longer a requirement, but more of a nicety. Therefore it no longer fits the scope of the requirements document. Sources
|
 |
|
| Copyright 2005-2009 OnPedia.com. All Rights Reserved |
|
|