| Moscow Method |
Article Index for Moscow |
Website Links For Moscow |
Information AboutMoscow Method |
| CATEGORIES ABOUT MOSCOW METHOD | |
| dsdm | |
| computer jargon | |
|
MoSCoW is a method 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 functional Requirement . It originated as part of the Dynamic Systems Development Method . Sometimes called a '''MoSCoW list''' or a '''MOSCOW Analysis'''. MoSCoW stands for:
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. 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. Must Have 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 '''U'''sable '''S'''ubse'''T'''. 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. 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. Wont 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. 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 useable subset" required to deliver the product. Response #2 Stakeholders in a new computer system will often come up with a wish list of every thing they can think might possibly be of use. To implement the whole wishlist 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 could-haves. SOURCES |
|
|