While researching for a presentation, the concept of “Moscow” was discovered. Its brilliance and its relevancy is as relevant today as it was when created in 1994 by Dai Clegg, of Oracle. Moscow represents a means of defining features for a product, or in our case, documentation priorities.
Those who are familiar with JIRA will be familiar with the High, Medium, and Low ratings. There are others as well. But somehow, once you learn about MoSCoW, it’s easy to see how this system is so much more relevant. Another term we often see is “showstopper.” Everyone understands that a showstopper means that without this feature being developed or this bug being fixed, the next release will not happen on time.
When evaluating your next version release (or documentation update), consider using MoSCoW.
What is a Must Have?
You can determine whether your feature or documentation element is a Must Have by asking yourself the following questions:
- What happens if it’s not included? Is the document viable without that section?
- No point in delivering without? (could be unsafe, illegal, not viable)
- Would some other feature be better?
- Will the consumer buy without this feature?
- Will this feature offer a unique benefits? (Better, lower cost, faster to use?)
What is a Should Have?
Should Haves don’t HAVE to be in the document, but they should be. They are topics that users don’t necessarily need, but may well notice are absent. Essentially, they are:
- Important but not vital
- Painful to leave out
- And yes, the end result may be well be considered less helpful
What is a Could Have?
While Could Haves are elements you’d like to have, they are a step below Should Haves in the following ways:
- You know they are likely to make it into the current release under any but the absolute best-case scenario
- They are important, but less than MUST/SHOULD
- Unlike Should Haves, missing Could Haves most likely don’t cause pain to users
- There is no question that the deadline is more important than the feature?
What is a Won’t Have?
Won’t Haves are probably the easiest to define and in many cases, you may well define these first. These go, without hesitation, to the back log. They are called Won’t Haves because there’s no question, from the very start. The upcoming release won’t have these features or documentation elements in them because:
- The feature is rated as less important to users
- Development “costs” don’t provide enough ROI
- Time framework puts project in overtime or would take more than one sprint to develop
How do you implement MoSCoW
Begin by assigning all features to the appropriate tag. If the document cannot be released without this section, it is a Must Have. If it’s something you’d prefer to have, if time allows, it is likely a Could Have. Each has it’s place and ranking and once each feature or documentation element is categorized, creating a realistic documentation plan is not difficult.
What MoSCoW does is provide you with a clear way to rate tasks in a way that is logical and easily recognized and understood by others. Rather than rating each task in relation to other tasks in or out of the current sprint, using MoCSoW means you are considering each feature for it’s own value. All Must Haves must be in the next release. And that’s where you begin, and end – with Moscow!