The MOSCOW method: a complete guide

What is the MoSCoW method?

MoSCoW is a prioritisation technique that divides project requirements, features, or tasks into four categories: Must Have, Should Have, Could Have, and Won't Have. The lowercase letters fill out the acronym into an actual word. The method was developed by Dai Clegg at Oracle in the 1990s, originally for software development projects, and has since been widely adopted across project management, product development, and planning more broadly.

The core problem MoSCoW solves is scope creep and unrealistic planning. When everything on a project list feels essential, teams tend to commit to more than they can deliver, underestimate risk, and then scramble when reality hits. MoSCoW forces a different question: given the time, budget, and resources available, what is the minimum that would make this project a success? That question, asked explicitly and agreed upon by everyone involved, tends to produce more honest plans and better outcomes than optimistic lists that assume everything will go smoothly.

The four categories

Must Have

Must Haves are the non-negotiable requirements without which the project fails or is not worth releasing. The test is strict: if you could remove something and the project would still work, even in a degraded form, it doesn't belong in Must Have. If you would cancel or abandon the project rather than deliver it without this item, it belongs here.

In practice, Must Haves define the minimum viable scope. They're the foundation everything else rests on. A product without its Must Haves isn't a product at all.

Should Have

Should Haves are important and expected, but the project remains viable without them. They're the items that will be painful to leave out, that stakeholders will notice and miss, but that don't constitute a fundamental failure of the project if they don't make it into the final release. Given enough time and resources, Should Haves get done. Under pressure, they're the first candidates for a later phase.

Could Have

Could Haves are desirable but clearly not essential. The difference between Should Have and Could Have is the degree of pain at their absence. Should Haves hurt; Could Haves are a mild disappointment. These are the nice-to-have features that get done when everything else is finished and there's capacity remaining. Under pressure, they go first.

Won't Have

Won't Have is arguably the most important category, and the most overlooked. Explicitly listing what won't be in this project or release does several things. It prevents scope creep by establishing shared expectations from the start. It makes clear that the absence of these items is a deliberate decision, not an oversight. And it gives stakeholders a place to put ideas and requests that are reasonable but not right for this project, rather than leaving them floating as implicit expectations.

Won't Have doesn't mean "never." It means not this time. A Won't Have in version one might be a Must Have in version two.

The 60/20/20 rule

MoSCoW comes with a resource allocation guideline designed to build slack into the project. Assign no more than 60% of total resources (time, budget, effort) to Must Haves. Allocate no more than 20% each to Should Haves and Could Haves.

The logic is about risk. Projects rarely go exactly to plan. Estimates are wrong, unexpected problems arise, dependencies slip. If 100% of your resources are committed to Must Haves, any deviation becomes a crisis. If Must Haves consume only 60%, you have a 40% buffer for the unexpected. In the worst case scenario, you complete only the Must Haves and still deliver a functional, releasable product. In a better scenario, you finish the Must Haves and move into Should Haves and Could Haves with the time remaining.

This means the Must Have list needs to be lean. If the honest answer is that your Must Haves alone take 80% of available resources, either your Must Have list is too ambitious (some items should be reclassified) or your resource estimate is too low and needs to be addressed before the project begins.

How to run a MoSCoW session

Gather the right people. MoSCoW works by aligning everyone who has a stake in the project: the people doing the work, the people commissioning it, and, where relevant, the people who will use it. The value of the method comes from forcing shared agreement, and that requires the right people in the room.

List everything. Before categorising, build a complete list of requirements, features, tasks, or deliverables. Don't try to categorise as you go. Capture everything first. This is similar to the GTD principle of capturing before clarifying: get everything out before making decisions.

Establish the constraints. Agree on the total resources available: time, budget, team capacity. Without a concrete constraint, the categorisation exercise becomes abstract. With one, the conversations get real quickly.

Categorise collaboratively. Work through the list together. For each item, the question is: given our constraints, where does this belong? Expect disagreement. That's the point. The friction of reaching agreement is doing useful work: it surfaces assumptions, reveals hidden dependencies, and produces a shared understanding of what the project actually is.

Verify the Must Have budget. Once everything is categorised, check that your Must Haves fit within 60% of available resources. If they don't, move items to Should Have. Keep adjusting until the categories are realistic.

Document the Won't Haves explicitly. Don't just let these disappear. Record them somewhere visible so that when someone asks about them later (and they will), there's a clear, agreed answer.

MoSCoW for personal projects

The method was designed for teams, but it transfers well to personal projects and planning. The value is similar: forcing yourself to be honest about what a project actually needs versus what you'd ideally like it to have.

If you're planning a side project, a research workflow, or even a home renovation, running through MoSCoW forces the same useful discipline. What would make this a success? What would I regret leaving out but could live with? What's actually a nice idea that I should stop pretending is necessary? What am I explicitly not doing this time?

Used in combination with the Ivy Lee Method, MoSCoW gives you a principled way to choose what goes on your daily list: Must Haves and Should Haves from your active projects, in that order.

When MoSCoW works well

Fixed-scope projects with real resource constraints. The method shines when there's a genuine constraint (a deadline, a budget, a team size) that forces trade-offs. Without a real constraint, the categories stay vague.

Projects with multiple stakeholders. MoSCoW is particularly valuable when different people have different ideas about what the project should include. The structured categorisation process surfaces those differences early, before they become problems mid-project.

Software and product development. The method's origins show here. Defining what a product does and doesn't include in a given release is exactly what MoSCoW is designed for.

When it works less well

Ongoing or open-ended work. MoSCoW is a project tool, not a daily task management tool. For work that doesn't have a defined scope or endpoint, the categories don't map cleanly onto what you're actually managing.

When constraints are unclear. The 60/20/20 rule requires knowing roughly how much any given item will cost in time or effort. If estimates are highly uncertain, the categorisation can feel arbitrary. In these cases, doing a rough sizing exercise before categorising helps.

When stakeholders can't commit to the Won't Have list. If everyone agrees in principle but the Won't Have list keeps getting reopened, MoSCoW is surfacing an alignment problem that needs to be resolved before the project can proceed well.

MoSCoW and other systems

GTD: GTD captures and organises everything you have to do. MoSCoW provides a prioritisation lens for deciding what gets done in a given phase or sprint. The two work at different levels: GTD manages the backlog, MoSCoW shapes the scope.

PARA: Within a PARA-organised workspace, MoSCoW helps you determine what goes into active Projects versus what gets parked in Resources for later. Must Haves and Should Haves become active project work; Could Haves and Won't Haves become backlog or future considerations.

Ivy Lee Method: The daily six tasks from the Ivy Lee Method should come from Must Haves and Should Haves in active projects. MoSCoW decides what matters at the project level; Ivy Lee decides what gets attention today.

Time blocking: Block time for Must Haves first, then Should Haves. This ensures the project's critical work gets protected calendar time rather than being squeezed by lower-priority items.

Kanban board: MoSCoW often pairs naturally with Kanban. The four categories can be used to label cards, or separate Kanban columns can be set up for each category during planning.

Frequently asked questions

Who should be in the room for a MoSCoW session?

Everyone with a stake in the project: the delivery team, the project sponsor or client, and any key users or subject matter experts. The value of MoSCoW comes from shared agreement, not from one person's view of priorities. Missing a key stakeholder from the session tends to produce a prioritisation that gets revised when they weigh in later.

What if stakeholders disagree about whether something is a Must Have?

Good. That's a disagreement worth surfacing now rather than after work has started. The facilitator's job in those moments is to return to the test: would the absence of this item cause you to cancel the project or consider it a failure? If the answer varies across stakeholders, you have a scope alignment problem that needs resolution regardless of the prioritisation framework you use.

How granular should the items be?

Granular enough to be actionable. "Build the reporting module" is probably too broad for a Must Have/Should Have distinction. "User can export data to CSV" is more useful. The right granularity depends on the project, but the test is whether you could estimate the effort required for the item as described.

Can items move between categories?

Yes. MoSCoW isn't a one-time exercise. As the project progresses and information changes, items can be reclassified. A Should Have that turns out to be technically impossible within the constraints might become a Won't Have. A Could Have that turns out to be trivial might get bumped to Should Have. The categories are a planning tool, not a contract.

Is MoSCoW the same as the Eisenhower Matrix?

They're related but different. The Eisenhower Matrix classifies tasks by urgency and importance, producing four quadrants. MoSCoW classifies project requirements by their necessity to the project's success, producing four categories. MoSCoW is specifically designed for project scope management; the Eisenhower Matrix is primarily a personal task prioritisation tool.

Can I use MoSCoW for personal tasks, not just projects?

Yes, with some adaptation. For a complex personal project (organising a large event, building something, planning a major transition), MoSCoW provides a useful structure for deciding what's essential versus desirable. For everyday task management, it's more overhead than most people need. The Ivy Lee Method or GTD's next actions tend to work better for daily task prioritisation.

The MoSCoW method was developed by Dai Clegg at Oracle in the 1990s and has been adopted across software development, project management, and agile frameworks.