MoSCoW is a prioritization framework that sorts requirements into four categories: Must have, Should have, Could have, and Won’t have. It was developed by Dai Clegg in 1994 for use with the DSDM (Dynamic Systems Development Method) framework and has since become one of the most widely used prioritization techniques in project management.

MoSCoW Prioritization Method: Sort Requirements by Necessity

Every project starts with more ideas than capacity. MoSCoW provides a simple, shared vocabulary for the conversation that turns a wishlist into a plan. Instead of debating priorities in abstract terms, stakeholders categorize each requirement into one of four clear buckets.

The Four Categories

Must Have (M)

Requirements without which the project is a failure. If a Must Have is not delivered, the product does not work, the regulatory deadline is missed, or the business case collapses. Must Haves are non-negotiable.

Test: “If this requirement is not delivered, can we still launch?” If the answer is no, it is a Must Have.

Examples for an e-commerce platform:

User can create an account and log in
User can add items to cart and complete purchase
Payment processing integration with Stripe
Order confirmation email

Must Haves should represent approximately 60% of total effort. If Must Haves consume 90% of capacity, there is no room for anything else and the project is at risk of delivering a bare-bones product even under ideal conditions.

Should Have (S)

Important requirements that are not strictly necessary for launch but whose absence causes significant pain or reduces value. Should Haves will be delivered if at all possible, but the project can launch without them if time runs short.

Test: “This is important, but we could work around its absence for the first release.”

Examples:

Saved payment methods for returning customers
Order history and reorder functionality
Email notification for shipping status updates
Customer review and rating system

Could Have (C)

Desirable requirements that improve the product but are the first to be cut when time or budget is constrained. Could Haves are nice-to-have enhancements that do not affect core functionality.

Test: “Users would appreciate this, but they won’t complain about its absence.”

Examples:

Wishlists and gift registry
Social sharing buttons on product pages
AI-powered product recommendations
Live chat support widget

Won’t Have (This Time) (W)

Requirements explicitly excluded from the current scope. This is not “never” — it is “not in this release.” Documenting Won’t Haves prevents scope creep by making exclusions explicit. When a stakeholder requests a feature that is on the Won’t Have list, the conversation is straightforward: “We agreed this is scheduled for a future release.”

Examples:

Mobile app (planned for Phase 2)
International shipping (planned for Q3)
Marketplace for third-party sellers (future consideration)
Cryptocurrency payment option (not planned)

Running a MoSCoW Session

Preparation

List all requirements. Pull from the product backlog, stakeholder interviews, and discovery documents. Each requirement should be specific enough to estimate effort.
Estimate effort. Before prioritizing, attach rough effort estimates (T-shirt sizes or story points) to each requirement. Without effort data, stakeholders will categorize everything as Must Have because they do not see the cost.
Define capacity. State clearly: “We have 500 story points of capacity for this release” or “We have 12 weeks with a team of 5.” This makes the constraint concrete.

The Session (60-90 minutes)

Participants: Product owner, project manager, key stakeholders, technical lead, and a representative from each discipline (design, QA, ops).

Step 1: Calibrate on Must Have. Start by discussing what “Must Have” truly means. Emphasize: the project fails without these. This prevents the common problem of everything being called a Must Have.

Step 2: First pass — individual categorization. Give each participant a copy of the requirements list and ask them to independently categorize each item. This prevents groupthink and surfaces genuine disagreements.

Step 3: Compare and discuss. Where categorizations align, accept the consensus. Where they disagree, discuss. A requirement that the product owner calls Must Have and engineering calls Could Have needs a conversation about business criticality versus technical complexity.

Step 4: Validate against capacity. Sum the effort of Must Haves. If Must Haves exceed capacity, the project scope needs renegotiation — either reduce the Must Have list or increase capacity. If Must Haves are well within capacity, verify that Should Haves fit. The remaining capacity after Must Haves and Should Haves determines how many Could Haves make it in.

Step 5: Document and distribute. Record the final categorization and share with all stakeholders. This becomes the reference document for sprint planning and change control decisions.

MoSCoW vs Other Prioritization Methods

MoSCoW vs RICE scoring. RICE (Reach, Impact, Confidence, Effort) produces a numerical score for each item, enabling ranked ordering. MoSCoW produces four buckets. Use RICE to rank items within each MoSCoW category — prioritize Must Haves by RICE score to determine build order.

MoSCoW vs Eisenhower Matrix. Eisenhower sorts by urgency and importance on two axes. MoSCoW sorts by necessity for project success. Eisenhower works better for personal task management; MoSCoW works better for product and project scope decisions.

MoSCoW vs Kano Model. The Kano model categorizes features by customer satisfaction impact (basic, performance, delight). It addresses customer value; MoSCoW addresses project scope. Use Kano to inform MoSCoW decisions — a Kano “basic” feature that customers expect is likely a Must Have.

Common Mistakes

Everything is a Must Have. When stakeholders categorize 80% of requirements as Must Have, the framework loses its value. Push back with the capacity constraint: “We can deliver 60 story points as Must Have. You’ve listed 120. Which 60 truly prevent launch if missing?”

Won’t Have feels negative. Reframe it. Won’t Have is not rejection — it is sequencing. “This is planned for Phase 2” is more palatable than “we won’t build this.” Some teams rename the category to “Won’t Have This Time” to emphasize the temporal nature.

No re-evaluation. MoSCoW categorization should be revisited at each major planning cycle. A Should Have from three months ago may now be a Must Have due to competitive pressure or customer feedback. Static prioritization in a dynamic environment leads to building the wrong things.

Skipping effort estimates. Without knowing what each requirement costs, stakeholders make prioritization decisions in a vacuum. The PM’s job is to pair every priority conversation with effort data so tradeoffs are real and visible.

MoSCoW works because it forces a binary decision at the Must Have boundary. Either the project fails without this requirement, or it does not. That clarity, uncomfortable as it is, prevents the priority inflation that plagues most projects and gives teams a defensible scope to execute against.