MoSCoW Prioritization Method Explained

7 min read ยท 2026-10-08

The MoSCoW method sorts requirements into four groups: Must have (the release fails without it), Should have (important but survivable if delayed), Could have (nice if time allows), and Won't have this time (explicitly out of scope for now). It is a scoping tool for a fixed deadline or budget, telling you what to protect and what to drop when time runs short.

This guide explains each category with concrete tests, how to keep Musts from ballooning, a worked example for a quarterly release, how MoSCoW combines with scoring frameworks, and a phased plan for applying it to your next quarter.

The roadmap at a glance

Goal: Use MoSCoW to define a realistic, protected scope for next quarter's product release. Duration: 2 weeks of scoping, then a 13-week quarter

  1. Frame the Time Box (Days 1-2)

    Establish the fixed deadline, capacity, and goal that MoSCoW decisions depend on.

    • Confirm the release deadline and whether it is genuinely fixed.
    • Calculate available team capacity in person-weeks after holidays and support duties.
    • Write a single release goal that defines what success means for this quarter.
    • Agree with the sponsor on who makes final calls on category disputes.

    Milestone: A written release goal, deadline, capacity figure, and named decision-maker.

  2. Collect Requirements (Days 3-5)

    Gather every candidate requirement in a comparable format.

    • Pull requirements from stakeholders, backlog, discovery findings, and compliance obligations.
    • Write each as a user story or short requirement with acceptance criteria.
    • Estimate each requirement roughly with engineering and design.
    • Note any dependencies between requirements before categorizing.

    Milestone: An estimated requirement list with dependencies noted.

  3. Categorize With Stakeholders (Days 6-8)

    Assign every requirement to Must, Should, Could, or Won't using agreed tests.

    • Start everything as Won't and require an argument to promote each item.
    • Apply the Must test by asking whether the release is pointless or illegal without it.
    • Separate Shoulds from Coulds by asking whether a workaround exists.
    • Record the reasoning for each Must so it can be challenged later.
    • Escalate unresolved disputes to the named decision-maker rather than splitting the difference.

    Milestone: Every requirement categorized with documented reasoning for each Must.

  4. Balance Against Capacity (Days 9-10)

    Make sure the categorized scope fits the time box with a safety margin.

    • Sum the effort for Musts and keep it to roughly 60 percent of capacity.
    • Fill about 20 percent with Shoulds and treat Coulds as the remaining contingency.
    • Demote Musts if they exceed the limit, revisiting the release goal if needed.
    • Sequence work so Musts start first and Coulds start last.

    Milestone: A balanced scope where Musts fit comfortably and Coulds act as contingency.

  5. Deliver and Defend Scope (Weeks 1-13 of the quarter)

    Use the categories to make fast tradeoffs when reality changes.

    • Track Must progress weekly and drop Coulds first when work runs over.
    • Require any new Must to displace existing scope of equal effort.
    • Review the Won't list at quarter end as input for next quarter's planning.
    • Report which Shoulds and Coulds shipped to show how contingency was used.

    Milestone: All Musts delivered on the deadline, with a clear record of what was traded away.

What Each Category Really Means

Must have items are non-negotiable for this release. A good test: if this item were missing, would you cancel or postpone the release? If the answer is no, it is not a Must. Legal requirements, core user flows, and anything that would make the product unsafe or unusable without it belong here.

Should have items are important and valuable, but the release still works without them, perhaps with a manual workaround or a temporary limitation. Could have items are desirable improvements with small impact if left out. Won't have this time items are explicitly out of scope for this release, which is not the same as rejected forever.

The method originated in the DSDM agile framework, where it was used to protect fixed deadlines by making scope the flexible variable. That origin explains its strength: it works best when time is fixed and you need to decide what gives.

  • Must: release fails or is cancelled without it.
  • Should: painful to omit, but a workaround exists.
  • Could: small benefit, first to drop.
  • Won't: agreed out of scope for this time box.

Keeping Must Haves Under Control

The classic failure is everything becoming a Must. Stakeholders learn quickly that only Musts get built, so they label everything Must. Counter this with a capacity rule: DSDM guidance recommends Musts take no more than about 60 percent of effort, leaving the rest as contingency for Shoulds and Coulds. If Musts exceed that, the scope is unrealistic and something must be demoted.

Another useful tactic is to start every item at Won't and make people argue it upward. This reverses the default, and the burden of proof falls on inclusion rather than exclusion. Writing down the reason for each Must also helps, because weak reasons become obvious when read aloud in a review.

A Worked Example for a Quarterly Release

A team is launching a self-serve billing portal by quarter end. Musts: customers can view invoices, update payment methods, and download receipts, plus tax handling required for compliance. Shoulds: plan upgrades and downgrades within the portal, and email notifications for failed payments. Coulds: usage charts and a dark theme. Won'ts: multi-currency support and reseller billing.

By week eight, the payment method update takes longer than estimated because of a payment provider integration issue. The team drops usage charts and dark theme immediately, keeps plan changes, and pushes failed payment emails to a fast follow-up. The launch date holds, Musts ship complete, and stakeholders already knew which items were at risk because the categories were agreed in advance.

Combining MoSCoW With Other Frameworks

MoSCoW does not rank items within a category. If you have twelve Shoulds and room for four, you still need a way to choose. Use a scoring method like RICE or a simple value versus effort matrix within each category to order items. This gives you both the clarity of MoSCoW groupings and a defensible order inside them.

MoSCoW also suits release scoping better than long-term roadmapping. For a quarterly roadmap, use outcomes or themes to decide which initiatives matter, then apply MoSCoW to the requirements of each initiative or release. That way the method stays focused on what it does best: protecting a deadline.

  • Use RICE or value versus effort to rank items within each category.
  • Use outcomes or themes to choose initiatives, MoSCoW to scope them.
  • Re-run MoSCoW at the start of every release or quarter.

Communicating MoSCoW Decisions

Share the full categorized list, including Won'ts, with stakeholders. Showing Won'ts openly prevents the same requests from resurfacing every week and signals that they were considered, not forgotten. Pair each Won't with the earliest point it will be reconsidered, usually the next planning cycle.

During delivery, report status by category. A simple update like "All Musts on track, one Should at risk, Coulds deprioritized" tells leadership almost everything they need in one line, and it keeps everyone aligned on what trades are acceptable.

Common mistakes to avoid

  • Labeling most items as Must removes the contingency MoSCoW depends on; cap Musts at roughly 60 percent of effort.
  • Using MoSCoW without a fixed time box makes categories meaningless; define the deadline and capacity first.
  • Treating Won't as rejected forever angers stakeholders; frame it as out of scope for this time box with a review date.
  • Leaving disputes unresolved stalls planning; name a single decision-maker before categorizing.
  • Assuming items within a category are equal leads to random choices; rank inside each category with a scoring method.
  • Starting Coulds before Musts are secure puts the deadline at risk; sequence work by category.

Frequently asked questions

What does MoSCoW stand for?

MoSCoW stands for Must have, Should have, Could have, and Won't have this time. The lowercase o letters are added only to make the acronym pronounceable. Each category describes how essential a requirement is to a specific release or time box, helping teams decide what to protect and what to drop when time is tight.

What is the difference between Must have and Should have?

A Must have is essential; without it the release is pointless, unsafe, or non-compliant, and you would delay the release rather than ship without it. A Should have is important and valuable, but the release still works without it, often with a workaround. Asking whether you would postpone the release is the quickest way to tell them apart.

How much of the work should be Must have?

A common guideline from DSDM is that Must haves should take no more than about 60 percent of the available effort, with Should haves around 20 percent and Could haves making up the rest. This leaves a buffer so the team can drop lower categories and still deliver every Must on time when estimates prove optimistic.

Is MoSCoW good for product roadmaps?

It works best for scoping a specific release or quarter with a fixed deadline. For long-term roadmapping, it is less useful because it does not rank items or connect them to outcomes. Many teams use themes, outcomes, or RICE to pick initiatives for the roadmap, then use MoSCoW to scope each release within those initiatives.

What does Won't have mean in MoSCoW?

Won't have means agreed out of scope for the current release or time box. It does not mean the idea is rejected permanently. Recording Won'ts explicitly prevents scope creep, shows stakeholders their requests were considered, and creates a ready list of candidates to review at the next planning session.

Generate this roadmap with AI