Moscow method

The MoSCoW Method is a prioritization framework that categorizes requirements into four groups: Must have, Should have, Could have, and Won't have (this time). Developed by Dai Clegg while working at Oracle, it provides a structured approach for making scope decisions and aligning stakeholders on what's essential versus what's optional. The technique is particularly useful when resources are constrained and trade-offs must be made explicit.

Why it matters

Every project faces more requirements than resources can address. Without clear prioritization, teams either try to do everything (and do nothing well) or make arbitrary cuts that frustrate stakeholders. Arguments about what's "important" become circular because everyone thinks their requirements matter.

MoSCoW cuts through this by forcing explicit categorization. Instead of debating whether something is important, you debate whether the project fails without it. This reframing produces clearer conversations and more defensible decisions. Stakeholders who understand the framework can participate meaningfully in prioritization rather than simply advocating for their features.

For product managers, MoSCoW provides a communication tool that makes scope conversations concrete. Instead of vague promises to "consider" requests, you can discuss which category something falls into and what would need to change for it to move categories.

The four categories

Each category represents a different relationship between requirement and project success.

Must have (Mo). Requirements that are non-negotiable for the current timebox. Without these, the project fails - it doesn't deliver its core purpose, violates regulations, or is literally unusable. If you can't deliver all Must haves, you should cancel the project or extend the timeline.

Should have (S). Important requirements that add significant value but that the project could survive without. These are painful to omit but not fatal. If Must haves consume available resources, Should haves are the first to be cut or deferred.

Could have (Co). Desirable requirements that would be nice to include if time and resources permit. These enhance the solution but their absence doesn't significantly diminish it. Could haves are often called "stretch goals."

Won't have (W). Requirements explicitly excluded from the current scope. This category is crucial - it acknowledges the requirement as valid but makes clear it's not happening now. "Won't have this time" prevents ambiguity about what's not included.

Applying moscow

Effective MoSCoW prioritization follows a disciplined process.

List all requirements. Start with a comprehensive list of what stakeholders want. This might come from a product backlog, requirements document, or stakeholder interviews.

Define the timebox. MoSCoW prioritizes for a specific period - a release, a sprint, a project. What's a "Won't have" for this release might be a "Must have" for the next. The timebox must be explicit.

Categorize collaboratively. Bring stakeholders together to categorize requirements. This isn't something product management should do in isolation - the value comes from shared understanding and negotiation.

Challenge Must haves. For each proposed Must have, ask: "What happens if we don't do this?" If the answer isn't "the project fails" or "we violate legal requirements," it's probably a Should have.

Validate capacity. Estimate the effort required for Must haves. If Must haves exceed capacity, you have a problem - either requirements need to move to lower categories or scope/timeline needs adjustment.

Document and communicate. The categorization should be documented and shared. The Won't have list is as important as the others - it sets clear expectations about what's excluded.

Moscow guidelines

Several rules help MoSCoW work effectively.

Must haves should be about 60% of effort. If everything is a Must have, nothing is. The constraint forces discipline about what's truly essential. Leaving room for Should and Could haves provides flexibility when Must haves take longer than expected.

Should and Could together should be about 40%. This buffer absorbs uncertainty. If everything goes well, you deliver more. If Must haves have problems, you cut from Should and Could.

Won't have is active, not passive. This category explicitly excludes items from scope. It's not a dumping ground for forgotten requirements but a clear statement of boundaries.

Categories are relative to the timebox. A "Won't have this release" might be a "Must have next quarter." Priorities evolve as context changes.

Revisit when circumstances change. If Must haves take longer than expected, Should haves might need to move to Won't have. If resources increase, Could haves might become achievable. The categorization reflects current understanding.

Benefits of moscow

The framework provides several advantages.

Clarity about trade-offs. Instead of vague prioritization ("high/medium/low"), MoSCoW makes the consequences of inclusion or exclusion explicit.

Stakeholder alignment. The collaborative categorization process builds shared understanding. Stakeholders who participated in prioritization are more accepting of what gets cut.

Scope management. The Won't have category creates explicit boundaries that prevent scope creep. When new requests arrive, they can be categorized against existing items.

Risk management. By ensuring Must haves don't consume all capacity, MoSCoW builds in buffer for uncertainty.

Communication tool. The framework provides vocabulary for scope discussions. "That's a Should have for this release" is clearer than "we'll try to fit it in."

Common mistakes

Several patterns undermine MoSCoW effectiveness.

Everything is a Must have. When stakeholders game the system by making everything "Must have," the framework breaks down. Challenge this by asking what specifically would fail without each item.

Ignoring the Won't have list. The Won't have category does the important work of setting expectations. Without explicit exclusions, stakeholders assume everything will eventually be included.

Using MoSCoW for estimation. MoSCoW is about priority, not effort. A small Must have and a large Could have might take similar time to implement but serve different purposes in the framework.

Setting priorities once. Priorities change as you learn more, as circumstances evolve, and as timeboxes shift. MoSCoW categorization needs regular review.

Categorizing without stakeholder input. When product management categorizes alone, stakeholders don't understand or accept the decisions. The collaborative process matters as much as the outcome.

Moscow vs. other frameworks

MoSCoW is one of many prioritization approaches, each with different strengths.

RICE (Reach, Impact, Confidence, Effort) provides numeric scoring for ranking items. It's more quantitative than MoSCoW but requires more data and judgment to score.

Kano categorizes features by customer satisfaction impact. It's focused on what customers value rather than project success.

Value vs. Complexity plots items on two axes to identify quick wins. It's visual and intuitive but less precise about categories.

MoSCoW excels when you need clear categories for scope conversations and when stakeholder alignment matters. It's simpler than scoring methods, making it accessible for collaborative workshops. It pairs well with other methods - you might use RICE to rank within categories or Kano to inform categorization.

When to use moscow

MoSCoW fits specific situations well.

Fixed-scope projects with clear end dates benefit from MoSCoW's category structure. The framework helps manage what's in and out.

Stakeholder negotiations where different groups want different things benefit from the explicit trade-off conversations MoSCoW enables.

Release planning where you need to decide what goes into this release versus future releases fits MoSCoW's timebox orientation.

Teams new to prioritization find MoSCoW's simple categories more accessible than quantitative scoring methods.

It's less suited to continuous product development where you're constantly adjusting priorities rather than planning fixed timeboxes, or to situations requiring fine-grained ranking of many similar items.

Making moscow work

Success with MoSCoW depends on discipline and facilitation.

Be rigorous about Must haves. The framework only works if Must have genuinely means "project fails without this." Challenge every Must have.

Use Won't have explicitly. Don't let requirements quietly disappear. Move them to Won't have and communicate what's excluded.

Involve the right stakeholders. People with authority to make trade-offs must participate. Junior representatives who can't commit waste everyone's time.

Revisit regularly. As you learn and as circumstances change, update the categorization. Stale prioritization is useless prioritization.

When used with discipline, MoSCoW transforms scope conversations from political battles into structured negotiations. Stakeholders may not get everything they want, but they understand why - and that understanding builds trust and alignment.