MoSCoW method has nothing to do with geography as the name might suggest. While managing a project it's important to understand the importance of each part of the work to be performed to keep to deadlines. MoSCoW is a prioritization method used to decide which requirements to complete first, which must come later and which to exclude. MoSCoW method originates from the dynamic software development method (DSDM).
The o's in the word MoSCoW are added to make it easier to pronounce and memorize, and therefore are in lowercase to show they don't stand for anything.
MoSCoW stands for:
Must have requirement to meet the business needs
Should have requirements that are important but not vital
Could have requirements that are desirable but less important
Won't have this time requirements
Must have requirement
- Not legal/unsafe without it
- Cannot deliver without it
Failure to deliver even one of them will likely mean the project has failed. If the answer to the question 'what happens if this requirement is not met?' is 'to cancel the project' then this is a must have requirement. If there is some way around it, even if it is a painful workaround, then it is a Should have or a Could have requirement.
Should have requirement
- May need some workaround
- Important but not vital
- May be painful to leave out but the solution is still viable
Should haves are important to the project or release, but they are not vital. If left out, the project still functions. However, if they are included, they add significant value. One way to tell a Should have requirement from a Could have requirement is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected. The project team should aim to deliver as many of the Should requirements as possible.
Could have requirement
- Desirable but less important
- Less impact if left out (compared with a Should have)
When the deadline is at risk or the budget comes under pressure, one or more of the Could have requirements are the first choice of what is to be dropped out.
Won't have requirement
- Not a priority for this specific timeframe
- Nice to have but has no real impact
- Get back to them at better days
Some initiatives in the 'will-not-have' group will get prioritized in the future, while others are not likely to happen at all. Some teams decide to differentiate between those by creating a subcategory within this group.
Where to start
Before using the MoSCoW method, you must ensure the teams involved in the project and other stakeholders agree on the project goals and the factors that will be used for prioritization. Teams should also discuss how they will settle any disagreements in prioritization.
Finally, you'll also want to reach a consensus on what percentage of resources you'd like to allocate to each category.
After the groundwork is complete, you can begin determining which category is most appropriate for each initiative.
As a software developer I have used MoSCoW method multiple times and can define the following pros and cons:Pros:
- Agility for scheduling and implementation
- Does not provide the order in which requirements are to be implemented within the individual categories
- Not effective if you have a complicated backlog
MoSCoW method is very effective when prioritizing work for small and not too complex products that do not have many technical limitations. Prioritizing work using MoSCoW is fast and transparent and is easy to master and use.