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:
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 successor something similar if using MoSCoW outside of a time-boxed process.
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 in a software development context. They are:
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 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:
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
Hierarchical MoSCoW - See the separate wiki page for the Hierarchical MoSCoW variant of this technique.
See the Prioritization wiki page for a discussion of why to prioritize.
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.
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:
Criticalmean. Achieving group consensus on definitions and criteria can be challenging.
Mustitems 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.