What is it?
MoSCoW Prioritization was originally invented by Dai Clegg of Oracle, but was subsequently donated to the Dynamic System Development Method (DSDM) Consortium. MoSCoW was designed to be used with time-boxing and although it is mostly referenced in regards to requirements, as the DSDM web site makes clear it “can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests.”
MoSCoW is among the most commonly used nominal-scale prioritization techniques, and as with every nominal-scale prioritization technique, there are a few important factors to consider when using this technique. They are:
- Because the result is assignment to a prioritized category, it is impossible to say if any one prioritized item is more or less important than any other item within the same category.
- Prioritization occurs within a single context only. There is only a single “prioritization in regards to what?” question being asked. Because MoSCoW was designed for use with time-boxing, the most common context criteria is “in regards to the time-box / release / version that is being planned at the time of prioritization”. But the context might also be “for overall project success” or something similar if using MoSCoW outside of a time-boxed process.
- Almost all prioritization efforts have a time-frame context (the priority assigned is based on the assumption of delivery within a specific time frame). This may be explicitly stated or not, but should always be identified and understood where possible.
As a nominal-scale prioritization technique, the MoSCoW process assigns prioritizes items to specific categories. In MoSCoW, those categories are Must, Should, Could, and Won’t. With the addition of a few lower-case “o’s” that have no meaning, those categories form the highly recognizable name of the technique.
The following are the definitions of the categories as specified in the DSDM Atern Handbook: 
Must Have items are those that have to be there in order to move forward. If you ask “What if X is missing?” and the answer is “We don’t proceed at all”, then you have found a “Must” item. But if there is some way to still proceed (such as making this a manually-processed step, something that can be added later, etc.), then you have found a “Should Have” or “Could Have” item.
The DSDM Atern Handbook gives several great criteria for identifying “Must Have” items is a software development context. They are:
- Cannot deliver on target date without this
- No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
- Not legal without it
- Unsafe without it
“Should Have” items differ from “Must Have’s” in that they are not absolutely required to move forward, but that their absence would cause a higher level of pain than “Could Have” items. Citing again from the DSDM Atern Handbook, where they provide several example criteria:
- Important but not vital
- May be painful to leave out, but the solution is still viable
- May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc.
“Could Have” category items are generally those that are desirable, but which have a smaller impact if left out than “Should Have” items. The difference is that “Should Have” items will generally impact a larger number of users, or create a greater burden on some critical users, if left out. A “Could Have” item is likely to impact fewer users, or create a smaller burden on users is left out. Where you put that cut-off will probably depend on your project, but it’s likely to be a point of contention.
And again, the DSDM Atern Handbook provides a few example criteria:
- Wanted or desirable but less important
- Less impact if left out (compared with a Should Have)
“Won’t Have” items are those which have been identified as being desirable or valuable, but which have categorized as not being in scope for a particular release, delivery phase, budget amount, or other cut-off point. They are NOT INVALID, they are just not being included “for now”.
Hierarchical MoSCoW – See the separate wiki page for the Hierarchical MoSCoW variant of this technique.
Why do it?
See the Prioritization wiki page for a discussion of why to prioritize.
How do I do it?
This assumes you have evaluated your prioritization needs and decided that MoSCoW is the technique you will use. See the “Prioritization Considerations” section of the Prioritization wiki page for more information.
Working with all stakeholders involved in the prioritization process, review and refine the proposed prioritization process. This includes such factors as what items will be prioritized, their relative level of abstraction, the criteria for assignment to a category, and how the decision to assign each item to a category will be decided if there is more than one person making the decision (voting, priority poker, etc.).
This information should be documented and approved by all stakeholders involved in the prioritization process. As a best practice, it is also a good idea to have all stakeholders who will consume the output of the prioritization process to review the criteria as well. The criteria documentation should be included with the prioritized information so that future consumers will understand what criteria where applied for prioritization category assignment.
Define the escalation process that will be used if agreement cannot be reached on the appropriate category that an item should be assigned to. This can include any standard conflict resolution process such as voting, sponsor over-ride, or any other mechanism that stakeholders and the project team can agree to. Defining the escalation process ahead of time should help prevent the prioritization process from getting bogged down or stuck on issues where there are conflicting priorities.
Define the prioritization context that will be used. Are you prioritizing for one of a sequence of releases? A single major development effort? For highest business value? To greatest efficiency? Is there a specific time-frame that the prioritization is being considered for? Like the assignment criteria in Step 1 above, this should be documented and kept with the prioritized items.
Gather the items that will prioritized (your requirements document, your product backlog, etc.) and organize them if necessary. The entire set of items should be at the same level of abstraction and the same type (requirement, task, user story, etc.).
Decide where the prioritization decision will be recorded and how. Will it be in the requirements document? A notation next to each item in a product backlog? A physical spot on a whiteboard? Will you use letters to designate the priority? Colors? Physical location?
With the stakeholder(s) involved, begin the prioritization process by going through the items one-by-one and assigning a prioritization category. All items should default to the “Won’t Have” category initially, with the stakeholder(s) having to justify why the item should be a higher priority.
Challenge all attempts to prioritize at the “Must” level. Based on the criteria defined in Step 1 above, the stakeholder(s) should be able to articulate why the item should prioritized at this level (for example: there is no manual work-around, the resulting solution would not be legal, etc.).
As each item is prioritized, the prioritization category should be recorded in the place and manner agreed up on Step 5 above.
After all items have been prioritized, go back through all items to ensure none have been missed.
If you have dependencies among the prioritized items (and know what those dependencies are), look for conflicts where a dependent item is prioritized higher than the item it is dependent on. If these are found, either the dependent item should be lowered in priority, or the item on which the dependency rests should be raised in priority.
Continue to re-evaluate the prioritization assignments as the situation changes. New items being added to the list, changes in the operating environment (such as changes to the project budget, scope, and timeline), and new information (such as different solution options) may all require a prioritization assignment to be changed.
What Should the Results be?
The results of a MoSCoW Prioritization exercise would be that all of the selected items have been assigned to an appropriate MoSCoW prioritization category based on:
- The category criteria agreed upon in Step 1
- Based on the context specified in Step 3
- In the manner specified in Step 5
- In the location specified in Step 5
- MoSCoW Prioritization is among the best techniques when there are a large number of items (50+) to be prioritized. And it is among the few techniques that is viable when there are a very large number of items (100+) to be prioritized.
- It is often easier for stakeholders to use than other prioritization techniques that may require stakeholders to define just how much of a higher priority one item versus another, with each item being compared to every other item.
- Stakeholders may have concerns about prioritization in general, which the terms used in MoSCoW can enhance. See reference below for a post from Ivar Jacobson International discussing this and a possible way of attempting to mitigate it.
- Ensuring a common understanding of exactly what criteria should be used for assigning an item to a particular category can often be difficult. Stakeholders often have their own internal understanding of what terms like “Must”, “Should”, “High”, and “Critical” mean. Achieving group consensus on definitions and criteria can be challenging.
- The DSDM Consortium recommends setting a limit on the percentage of items that can be assigned to any one MoSCoW priority category (for time-boxed development at least). They recommend no more than 60% in Must, 20% in Should, and 20% in Could.
- If you need ratio or ordinal scale results (see the Prioritization wiki page), you can reduce your item set by using MoSCoW Prioritization to first divide your items into MoSCoW categories, and then use a technique that delivers ratio or ordinal results on just the items in the non-Must groups separately (since “Must” items are mandatory, there is probably no need to prioritize them further). This cuts larger item sets down to smaller sets that work better with the more detailed analysis required for those techniques.
- Research Paper: A Comparison of Nine Basic Techniques for Requirements Prioritization. By Mikko Vestola. Helsinki University of Technology.
- Wikipedia Page: MoSCoW Method. Accessed June 9, 2013.
- DSDM Atern Handbook. MoSCoW Prioritization. By the DSDM Consortium. Accessed on May 20, 2014.
- Article: First Things First – Prioritizing Requirements. By Karl Wiegers. Software Development. September 1999.
- Blog Post: MoSCoW Anxiety. By Ivar Jacobson International. March 1, 2012.
- Book Chapter: Requirements Prioritization. By Patrik Berander and Anneliese Andrews. In Engineering and Managing Software Requirements. Edited by A. Aurum and C. Wohlin. Springer Verlag. 2005.
- Article: MoSCoW Prioritization Isn’t From Russia. By Ric McLaughlin. October 2011.
- Article: MoSCoW Prioritization. By Coley Consulting.
- Article: How I Stopped Worrying and Learned to Love Prioritization. By Jeff Patton on AgileConnection. 29 August 2008.
- Blog Post: Has Your Backlog Been to MoSCoW? By Richard Mouser. 14 November 2012.
- Blog Post: MoSCoW Prioritization Poker. By Morgan Ahlstrom. October 20, 2011.