MoSCoW Method: Prioritization Guide & Example [2026]

Ask five stakeholders to rank their requirements and you will receive five lists in which everything is a top priority. Priority stops meaning anything when everything has it, and a team that tries to deliver it all usually delivers the important items late. The MoSCoW method fixes this with four plain words that force a real choice. This guide explains the MoSCoW method in full: what each category means, how much of the work should be a must-have, how to run a MoSCoW session step by step, a worked example, how MoSCoW compares to other prioritization techniques, and how it appears on the PMP and CAPM exams.

What is the MoSCoW method?

The MoSCoW method is a prioritization technique that sorts requirements into four categories: must have, should have, could have, and won't have (this time). Each category answers one question about a requirement. Can the release succeed without it? If not, it is a must-have. If it can, the remaining categories rank how much it matters.

The method is a standard part of project management practice. The PMBOK® Guide, Eighth Edition, lists MoSCoW among the commonly used methods for prioritizing requirements, alongside the 100-point method, cost of delay, and Kano analysis. The Agile Practice Guide includes it in its table of common backlog prioritization techniques. For that reason, a candidate preparing for the PMP exam should know the method well enough to apply it, not just to recite the acronym.

MoSCoW is usually applied right after requirements gathering. Once the stakeholders' needs are documented, the team still has to decide which of them the project will deliver first, and which it will not deliver at all in the current timeframe.

Where the MoSCoW method comes from

The MoSCoW method was created by Dai Clegg in 1994, while he was working at Oracle UK on rapid application development projects. It was then adopted by the Dynamic Systems Development Method (DSDM), one of the early agile frameworks.

Today the method is maintained by the Agile Business Consortium, the not-for-profit body behind DSDM. Their description of MoSCoW prioritization remains the reference definition of the categories and the recommended effort split. Note that the method was born in timeboxed delivery, where the deadline is fixed and the scope must flex. This origin explains most of its rules.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

The four MoSCoW categories

The four MoSCoW categories are must have, should have, could have, and won't have (this time). Each one is decided by a simple test, so two people applying the method to the same requirement should reach the same answer.

The must-have category is the heart of the method. The Agile Business Consortium describes it as the minimum usable subset of requirements that the project guarantees to deliver. For example, a payment system that cannot take payments is not a smaller release. It is a failed one.

The won't have (this time) category is the most misunderstood. It does not mean "never." It means the stakeholders have agreed that the item will not be delivered in this timeframe. Recording these items is important for scope control. Because the decision is written down, the item cannot quietly return to the project later without a formal decision. As a result, a well-kept won't-have list is one of the simplest defenses against scope creep.

How much should be a must-have?

The Agile Business Consortium recommends that must-haves take up no more than about 60% of the team's effort in a timeframe, with about 20% of the effort in could-haves. The remaining effort goes to should-haves. Won't-haves are excluded from the calculation.

The logic is contingency. In MoSCoW, everything below a must-have is a buffer that protects the must-haves. If estimates prove too optimistic, the team drops could-haves first, then should-haves, and the must-haves are still delivered on time. If must-haves consume 85% or 90% of the effort, there is almost nothing left to drop. In that case, any estimating error threatens the release itself.

Consider a timebox with 100 days of available effort. Must-haves estimated at 60 days leave 40 days of flexible work around them. If one must-have runs 15 days over, the team removes a could-have and a should-have, and the must-haves still finish. Must-haves estimated at 90 days leave only 10 days of buffer, and the same overrun breaks the release.

How to use the MoSCoW method step by step

The MoSCoW method works best as a short, structured session with the right people in the room. The following steps describe a typical approach.

1. Agree the rules first. Before any requirement is categorized, agree what each category means for this project, who makes the final call when stakeholders disagree (often the product owner or sponsor), and the target effort split.
2. List the requirements. Start from the documented requirements or the product backlog. Each item should be clear enough to estimate.
3. Apply the must-have test to every item. Ask what happens if the item is not delivered. Only items whose absence means failure become must-haves.
4. Sort the rest. Place the remaining items into should have, could have, or won't have (this time).
5. Check the effort split. Compare the must-have effort with the available capacity. If must-haves exceed about 60% of the effort, challenge them again before committing.
6. Record and communicate. Publish the categorized list, including the won't-haves, so every stakeholder sees the same decisions.
7. Revisit at every boundary. Priorities change. Review the categories at the start of each release or iteration, and route any change to a baselined commitment through the project's agreed change process.

Note that step 1 is the one teams skip most often. When the decision rules are agreed only after the arguing starts, the loudest stakeholder tends to win.

MoSCoW prioritization example

Consider the customer self-service portal used in our requirements traceability matrix example. The team prioritizes the requirements for the first release, which has a fixed launch date.

Read the example as a set of decisions, not labels. Search speed is a should-have only because a workaround exists (customers can wait an extra second). The chat widget is a won't-have this time because of a constraint, not because nobody wants it. If a developer builds the chat widget anyway, that is unapproved work, a pattern explained in our guide to gold plating.

MoSCoW in agile and predictive projects

MoSCoW is most common in agile projects, where the timebox is fixed and the scope flexes. In that setting, the team uses it to decide what goes into each release and iteration. A minimum viable product must include all of the must-have requirements, since the must-haves are, by definition, what the product cannot work without.

In agile projects, MoSCoW is often used alongside the ordered product backlog. The categories sort the backlog into broad groups, and the product owner then orders the items within each group.

MoSCoW also works in predictive projects. Before the scope is defined, the team can use it to decide which requirements enter the project scope statement and which are deferred to a later phase. Once the scope is baselined, the categories are no longer moved freely. Any change to approved scope goes through change control.

Pros and cons of the MoSCoW method

The Agile Practice Guide summarizes MoSCoW in two phrases: "fast for workshops" and "coarse-grained and subjective." Both are accurate.

Advantages

• Simple and fast. Anyone can learn the four categories in minutes, which makes MoSCoW ideal for workshops with business stakeholders.
• Forces real trade-offs. The must-have test and the effort limit stop a team from treating everything as top priority.
• Builds shared understanding. Stakeholders see the same categories and the same won't-have list.
• Protects the deadline. Lower categories act as contingency for the must-haves.

Disadvantages

• Everything becomes a must-have. If stakeholders fear that anything lower will never be built, they inflate their must-haves and the method collapses.
• No order inside a category. MoSCoW groups items but does not rank them. A second technique is needed to sequence the must-haves.
• Subjective. Categories depend on judgment unless the decision rules are agreed in advance.
• Ignores dependencies. A could-have that a must-have depends on must be treated as part of that must-have.

MoSCoW vs. other prioritization techniques and frameworks

MoSCoW is one of several prioritization techniques and frameworks in PMI's guidance. The Agile Practice Guide lists the following common options, and each answers a slightly different question.

In practice, teams combine them. A common pattern is MoSCoW first, to agree what is in the release, followed by a stack rank or WSJF inside the must-have group to decide the build order.

MoSCoW prioritization template

A MoSCoW template needs only a few columns. The simplest version is a table with one row per requirement.

• Requirement ID and description, written clearly enough to estimate.
• Category (must, should, could, or won't have this time).
• Rationale, one sentence that records why the item landed in its category.
• Effort estimate, so the team can check the must-have share against capacity.
• Owner or source, the stakeholder who raised the requirement.
• Revisit date, for won't-have items that are deferred rather than dropped.

The rationale column is the one most templates leave out, and it is the most useful. When the categories are challenged later, a written reason settles the discussion faster than anyone's memory.

The MoSCoW Method on the PMP® and CAPM® Exams

In the PMP exam, every question arrives as a scenario, and MoSCoW questions are no exception. You will rarely be asked what the letters stand for. Instead, you will see a team whose must-haves no longer fit the timebox, stakeholders who label every item a must-have, or a sponsor who wants to move a won't-have back into the release. If a question asks what the project manager should do, look for the answer that applies the method's logic: test the must-haves honestly, protect them with lower-priority work, and keep agreed decisions visible.

Note that in the exam, the obvious move is often a distractor. Dropping the lowest category sounds like textbook MoSCoW, but it fails when the categories themselves are wrong. Committing to everything with overtime fails because it ignores the contingency the method depends on. Our best-selling PMP Complete Study Guide, the most complete study guide on the market, covers prioritization and the agile backlog the way the exam tests them.

The CAPM® exam tests MoSCoW in the same situational way, with shorter and more contained scenarios. CAPM questions on prioritization usually sit in the agile and business analysis domains, where a requirement must be placed in the right category or a timebox must be rebalanced. Candidates starting from zero can learn the method step by step in our CAPM Certification Training.

PMP Practice Question: MoSCoW Method

A project manager is leading release planning on a hybrid project to deliver a bank's new loan-application portal before a regulator-imposed deadline. Stakeholders prioritized the requirements with the MoSCoW method, producing 14 must-haves, 3 should-haves, and no could-haves. During the session, several stakeholders admitted they had labeled items as must-haves because, on past projects, anything lower was never delivered. The team's estimates show that the must-haves alone would consume about 85% of the effort available before the deadline. The sponsor declares the categories final and asks the team to commit to all 17 items.

What should the project manager do next?

a) Commit to the 17 items and protect the deadline by planning overtime and adding a contingency reserve for the should-haves.

b) Move the 3 should-haves to won't have (this time) so the team can commit to the 14 must-haves, with the remaining effort as a buffer.

c) Review each must-have with the stakeholders against the test of whether the release would fail without it, re-categorize the items that do not pass, and rebalance before committing.

d) Submit a change request with an impact assessment of the excess effort so the change control board can decide which items will be delivered.

Correct answer: C.

Rationale: The decisive fact is the stakeholders' admission that they inflated their must-haves out of fear. That turns this into a problem with the categories themselves, not with capacity. Option b) is the tempting reflex because it is textbook MoSCoW: drop the lowest category to protect the must-haves. It fails here because it treats the inflated labels as valid. The team would commit to 85% must-have effort with no could-haves as contingency, so any estimating error would break a regulatory deadline. Option a) obeys the sponsor and commits to everything, which ignores the method's core logic that lower priorities are the buffer for the must-haves. Overtime and reserves cannot replace an honest priority list. Option d) borrows the correct answer from a different situation. A change request with an impact assessment is right when work affects an approved baseline, but this is release planning and nothing has been baselined yet. The priorities are still being set, so they are fixed by collaborative analysis, not by a change control board. Option c) applies the must-have test that defines the category. It removes the inflation, restores the contingency, and gives the sponsor a commitment the team can actually keep. PMI's way is to analyze and collaborate before committing, not to accept labels that the facts contradict. For full-length, realistic, scenario-based practice with detailed explanations, built to train the PMI® mindset, take our PMP practice exams or, at the entry level, our CAPM practice exams.

Ready to take the next step in project management?

200,000+ Professionals Taught by Our Instructors

PMP® Certification Training

PMP Training →

CAPM® Certification Training

CAPM Training →

Learn Project Management

PM Course →

Frequently asked questions