MoSCoW Prioritization

IMPORTANT! If you are going to use any prioritization method, be sure that you actually implement more than just the highest level of priority items. If stakeholders consistently see that all that will implemented are the highest priority items, then soon they will stop believing that priority levels mean anything and that everything that is not flagged as the highest priority will not get implemented. And if that occurs, then either everything your clients prioritize will be the highest priority or they simply will no longer cooperate because they have lost confidence in the process.


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.[2]  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.[3]

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:

  1. 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.
  2. 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.
  3. 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: [3]


Must Have

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 in a software development context. They are:[3]


Should Have

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:


Could Have

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:[3]


Won't 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.


Step 1

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.


Step 2

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.


Step 3

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.


Step 4

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.).


Step 5

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?


Step 6

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.


Step 7

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.).


Step 8

As each item is prioritized, the prioritization category should be recorded in the place and manner agreed up on Step 5 above.


Step 9

After all items have been prioritized, go back through all items to ensure none have been missed.


Step 10

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.


Step 11

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:









  1. Research Paper: A Comparison of Nine Basic Techniques for Requirements Prioritization. By Mikko Vestola. Helsinki University of Technology.
  2. Wikipedia Page: MoSCoW Method. Accessed June 9, 2013.
  3. DSDM Atern Handbook. MoSCoW Prioritization. By the DSDM Consortium. Accessed on May 20, 2014.
  4. Article: First Things First - Prioritizing Requirements. By Karl Wiegers. Software Development. September 1999.
  5. Blog Post: MoSCoW Anxiety. By Ivar Jacobson International.   March 1, 2012.
  6. 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.

Related Resources