Prioritization
The MoSCoW Method
The MoSCoW method is a prioritization technique that sorts requirements or tasks into four categories: Must have, Should have, Could have, and Won't have.
Overview
The MoSCoW method is a prioritization technique that sorts requirements or tasks into four categories: Must have, Should have, Could have, and Won't have. It was developed by Dai Clegg for use in project management, particularly within the Dynamic Systems Development Method (DSDM) framework. The method provides a simple, structured way to reach agreement on what is essential, what is important but not critical, what is desirable but optional, and what is explicitly out of scope. By forcing a clear distinction between these levels, MoSCoW helps teams avoid the common trap of treating everything as a top priority. It is especially useful when time or resources are fixed and scope must be negotiated. The acronym is easy to remember, and the categories are intuitive, making it accessible to both technical and non-technical stakeholders. MoSCoW is typically applied in a single sorting session, where items are reviewed and assigned to one of the four buckets. The result is a prioritized list that guides planning, resource allocation, and expectation management. Because it is ad-hoc, it can be used whenever a new set of requirements or tasks needs to be prioritized, such as at the start of a project, during sprint planning, or when scope changes arise.
How it works
The MoSCoW method operates by assigning each item to one of four categories. Must have items are non-negotiable; without them, the project or deliverable is considered a failure. Should have items are important and add significant value, but their absence does not cause failure; they can be worked around if necessary. Could have items are nice to have and provide marginal value; they are the first to be dropped if time or resources are constrained. Won't have items are explicitly agreed to be out of scope for the current time frame; they are not ignored but deferred or excluded. The method works best when the categories are clearly defined and agreed upon by all stakeholders before sorting begins. Typically, a facilitator guides the group through each item, prompting discussion until consensus is reached. The key is to avoid overloading the Must have category; a common guideline is that Must haves should not exceed 60% of the total effort, though this is not a strict rule. The output is a prioritized list that can be used to make decisions about what to include in a release, sprint, or project phase. Because the categories are mutually exclusive and collectively exhaustive, the method provides a clear picture of what is truly essential versus what is optional.
Step-by-step
1. Gather a list of all candidate items: requirements, tasks, features, or deliverables. Ensure the list is comprehensive but not overly detailed; each item should be a distinct unit of work. 2. Define the four categories clearly for the group. Explain that Must have means failure without it, Should have means important but not critical, Could have means optional, and Won't have means out of scope for now. 3. Set a target for the Must have category, such as no more than 60% of estimated effort, to prevent overload. 4. Review each item one by one. For each, ask: Is this essential for success? If yes, assign to Must have. If no, ask: Is it important but not essential? If yes, assign to Should have. If no, ask: Is it desirable but not important? If yes, assign to Could have. If no, assign to Won't have. 5. Encourage discussion to resolve disagreements. Aim for consensus, but if consensus is not possible, the decision-maker (e.g., product owner) makes the final call. 6. Once all items are categorized, review the Must haves to ensure they are truly essential. If the list is too long, re-evaluate and move some to Should have. 7. Document the final prioritization and communicate it to all stakeholders. Use it to guide planning and to manage scope changes. 8. Revisit the prioritization as needed, especially when new information emerges or when scope changes. Because the method is ad-hoc, there is no fixed schedule; apply it whenever a new prioritization is needed.
When to use it
The MoSCoW method is particularly useful in situations where scope must be negotiated against fixed time and resources. It is commonly used in project management, software development, and product management, but it can be applied to any set of tasks or requirements that need prioritization. Use it when you have a large list of potential work and need to separate the essential from the optional. It is also helpful when stakeholders have differing opinions on what is important, as it provides a structured framework for discussion. The method is simple enough to be used in a single meeting, making it ideal for kickoff sessions, sprint planning, or release planning. It works well when you need to communicate clearly what will and will not be delivered, as the Won't have category explicitly sets expectations. However, it may not be suitable for complex prioritization where items have multiple dimensions of value, such as cost-benefit analysis or risk assessment. In those cases, a more quantitative method like weighted scoring may be better. MoSCoW is best for separating musts, shoulds, coulds, and won'ts, and it excels when the goal is to reach a quick, consensus-based prioritization. It is ad-hoc, so use it whenever the need arises, not on a fixed schedule.
Common pitfalls
One common pitfall is overloading the Must have category. When too many items are labeled as Must have, the prioritization loses its power, and the team is no better off than before. To avoid this, set a guideline for the maximum proportion of Must haves and enforce it. Another pitfall is treating Should have items as Must haves in disguise. If an item is important but not essential, it belongs in Should have, and the team should be prepared to drop it if necessary. A third pitfall is failing to define the categories clearly, leading to inconsistent assignments. Ensure everyone understands what constitutes a Must have versus a Should have. A fourth pitfall is not involving the right stakeholders. Prioritization should include those who have authority to make decisions and those who will be affected by them. A fifth pitfall is ignoring the Won't have category. Explicitly stating what is out of scope is as important as stating what is in scope, as it manages expectations and prevents scope creep. Finally, avoid using MoSCoW as a one-time exercise. Priorities can change, so revisit the categorization when new information emerges or when the project context shifts. Because the method is ad-hoc, there is no set cadence, but regular reviews can help keep priorities aligned with current goals.
Combining with other methods
MoSCoW can be combined with other prioritization methods to create a more robust approach. For example, you can use a scoring method like weighted scoring or the Eisenhower Matrix to initially rank items, then apply MoSCoW to categorize them into actionable buckets. This two-step process can help when there are many items and you need a more quantitative basis for discussion. MoSCoW also pairs well with Agile frameworks such as Scrum or Kanban. In Scrum, MoSCoW can be used during backlog refinement to prioritize user stories before sprint planning. In Kanban, it can help set work-in-progress limits by focusing on Must haves first. Another useful combination is with cost-benefit analysis; after categorizing items with MoSCoW, you can estimate the cost and benefit of each to further refine priorities. MoSCoW can also be used alongside the Kano model to understand customer satisfaction drivers, then prioritize features accordingly. When combining methods, be clear about the purpose of each: use MoSCoW for quick, consensus-based categorization, and use other methods for deeper analysis. Avoid overcomplicating the process; the strength of MoSCoW lies in its simplicity. Finally, you can integrate MoSCoW with roadmapping tools to visually communicate what is planned for each release or phase. The key is to use MoSCoW as a complement, not a replacement, for other techniques.
Frequently asked questions
Q: How many items should be in each category? A: There is no fixed number, but a common guideline is that Must haves should not exceed 60% of the total estimated effort. Should haves might be around 20%, Could haves around 20%, and Won't haves are whatever is left out. The exact distribution depends on the context, but the goal is to keep Must haves truly essential. Q: Can an item move between categories? A: Yes, items can and often should move as new information becomes available or as priorities change. MoSCoW is not a one-time exercise; it is ad-hoc, so revisit the categorization when needed. However, frequent changes can undermine stability, so aim for a balance. Q: Who should be involved in the MoSCoW session? A: Include key stakeholders such as the product owner, project manager, development lead, and representatives from business or user groups. The session should be facilitated by someone who can guide discussion and ensure the categories are applied consistently. Ultimately, the decision-maker (e.g., product owner) should have the final say if consensus cannot be reached. Q: Is MoSCoW suitable for personal task management? A: Yes, it can be used to prioritize personal tasks or goals. For example, you can categorize your to-do list into Must do, Should do, Could do, and Won't do for the day or week. It helps focus on what truly matters.