Objective Prioritisation: MoSCoW

This is one of RoadmapOne’s articles on Objective Prioritisation frameworks .

Most prioritisation frameworks optimise for value per effort. MoSCoW optimises for a different problem entirely: what do we cut when the deadline is immovable and scope is negotiable? Born in software development’s fixed-bid contract era, MoSCoW—Must have, Should have, Could have, Won’t have—forces teams to classify every objective by criticality. When launch day arrives or the budget runs out, you ship the Must-haves, negotiate the Should-haves, abandon the Could-haves, and explain why the Won’t-haves never belonged on the roadmap.

Unlike RICE or ICE, which multiply dimensions into numeric scores, MoSCoW uses categorical buckets. There’s no formula, no arithmetic, just brutal binary choices: Is this objective mission-critical, or can the product survive without it? That simplicity is MoSCoW’s power and its curse. It’s clarifying when deadlines loom and scope must shrink. It’s dangerous when teams use it to sandbag expectations or when stakeholders game the buckets to inflate their priorities.

Sign up now to negotiate scope with MoSCoW

The Four Categories of MoSCoW

MoSCoW divides objectives into four buckets, each representing a different criticality level. The categories aren’t scores to optimise—they’re commitments about what happens when time runs out. Teams debate and assign each objective to exactly one bucket, then use those classifications to make ruthless scope cuts under pressure.

Must Have: The Non-Negotiables

Must-haves are objectives without which the product fails to deliver its core value proposition. If you’re building a payment system, processing transactions is a Must-have. If you’re launching a mobile app, the app must actually launch on iOS and Android. Must-haves aren’t “really important” or “high priority”—they’re existential. Without them, the product is worthless or the project violates its fundamental commitments.

The discipline of Must-have classification is restraint. Teams habitually label everything Must-have because no one wants their objective to be deprioritised. The test is simple: If we launch without this, does the product fail to solve its primary problem? If the answer is “no, but users will be disappointed,” it’s not a Must-have—it’s a Should-have dressed up to look critical.

Must-haves should represent 30-50% of total scope, not 90%. If you’ve labelled 80% of objectives as Must-have, you’re lying to yourselves and setting up a scope disaster. The cure is public shame: track past projects, identify objectives labelled Must-have that shipped late or got cut, and ask why something “non-negotiable” turned out to be negotiable when the deadline hit.

Should Have: The Important but Not Critical

Should-haves are objectives that significantly improve the product but aren’t required for core functionality. They’re the difference between “barely viable” and “actually good.” If you’re launching an e-commerce platform, Must-haves are product listings and checkout; Should-haves are wishlist functionality, product reviews, and recommendations. Users expect them, but the platform technically works without them.

Should-haves are MoSCoW’s negotiation layer. When the deadline approaches and Must-haves are slipping, Should-haves get deferred to version 1.1. When the project is ahead of schedule, Should-haves get promoted into scope. They’re the buffer that absorbs uncertainty and keeps Must-haves protected.

The trap is Should-have inflation. If teams overload the Should-have bucket with 200 objectives, the category becomes meaningless. The fix is capacity-based limits: if you have 12 weeks and six developers, you can realistically deliver 8-12 Must-haves and maybe 5-8 Should-haves. Force the Should-have list to fit that constraint, or admit you’re playing wishlist games instead of planning delivery.

Could Have: The Nice-to-Haves

Could-haves are objectives that would be delightful but are clearly optional. They’re polish, convenience features, and “wouldn’t it be cool if…” ideas. In the e-commerce example, dark mode is a Could-have. So is advanced filtering, social sharing, and animated transitions. They make the product better, but no one’s blocking the launch over their absence.

Could-haves serve two purposes. First, they’re the aspiration layer—what you’d love to ship if time permits. Second, they’re the first things cut when deadlines tighten. Could-haves are explicitly not commitments; they’re hopes. Stakeholders who push for their Could-haves to be upgraded to Should-haves must argue why the objective crosses from “nice” to “significantly improves product value.”

The danger is treating Could-haves as secret Should-haves. Teams label objectives “Could” to avoid political fights, then act surprised when they don’t get resources. If something truly matters, label it Should-have and defend the classification. Could-haves that get built are windfalls, not plans.

Won’t Have: The Out-of-Scope

Won’t-haves are objectives explicitly excluded from the current release—either permanently or deferred to future versions. They’re ideas that sparked debate, got seriously considered, and were rejected. Won’t-haves aren’t ignored; they’re documented decisions. Listing them prevents zombie objectives from resurging mid-project because someone “forgot” they were out of scope.

Won’t-haves are MoSCoW’s scope contract. When stakeholders ask “what about that feature we discussed?” you point to the Won’t-have list and say “we explicitly decided that’s out of scope for v1.” The list protects teams from mid-flight requirements creep and gives product managers political cover to say no.

The key is documenting why objectives are Won’t-haves. “Out of scope” isn’t enough. “Out of scope because it requires ML infrastructure we don’t have” or “deferred to v2 pending validation data” gives context. When the next release planning cycle starts, Won’t-haves with documented rationale can be reconsidered intelligently instead of rehashing old debates.

MoSCoW in Action

MoSCoW doesn’t produce numeric scores—it produces categorical commitments. Consider a mobile app launch with 25 objectives:

Must-Haves (10 objectives):

• User authentication
• Core content browsing
• Offline mode
• Crash reporting
• Push notifications
• Profile creation
• Settings management
• Basic search
• Content detail view
• iOS and Android builds

Should-Haves (8 objectives):

• Social sharing
• Advanced filtering
• Bookmarking
• Comment threads
• In-app feedback
• Onboarding tutorial
• Dark mode
• Analytics dashboard

Could-Haves (5 objectives):

• Personalised recommendations
• Gamification badges
• Animated transitions
• Voice search
• AR preview features

Won’t-Haves (2 objectives - documented for scope protection):

• Web version (planned for v2 after mobile validation)
• Paid subscription tiers (planned for Q3 after free user validation)

The Must-haves define minimum viable product. The Should-haves are stretch goals if the team stays on schedule. The Could-haves are moonshots if everything goes perfectly. The Won’t-haves are documented to prevent scope creep. When launch day arrives and six Must-haves are done, four are in progress, the team knows exactly what to communicate: we’re shipping core functionality, deferring some Should-haves to version 1.1, and explicitly not including Could-haves or Won’t-haves.

This is MoSCoW’s strength: it creates unambiguous scope commitments and provides a transparent negotiation framework when reality diverges from plans.

When MoSCoW Is Your Best Weapon

MoSCoW excels in three contexts. First, fixed-deadline projects with immovable launch dates. Regulatory compliance deadlines, contractual commitments, event-driven releases—when the date can’t move, scope must. MoSCoW makes those scope trade-offs explicit and defensible before the deadline pressure hits.

Second, stakeholder alignment on non-negotiables. When executives, customers, and engineering have wildly different views on what’s “critical,” MoSCoW forces the debate into the open. Must-haves require unanimous agreement; if someone vetoes, it’s not a Must-have. The framework creates a forum for resolving priority conflicts before they torpedo delivery.

Third, communicating scope risk to non-technical stakeholders. Boards and executives don’t intuitively grasp RICE scores or WSJF calculations, but they understand “Must have, Should have, Could have, Won’t have.” MoSCoW’s plain language makes roadmap trade-offs accessible to anyone, eliminating the “why wasn’t my feature built?” confusion.

When MoSCoW Betrays You

MoSCoW collapses in three scenarios. First, when everything becomes a Must-have. Teams avoid hard trade-offs by classifying 80% of objectives as “critical,” rendering the framework useless. Without discipline and willingness to fight political battles, MoSCoW devolves into wishful thinking with category labels instead of realistic scope commitments.

Second, when value optimisation matters more than deadline survival. MoSCoW doesn’t optimise for impact, reach, or value per effort—it only optimises for “what’s critical?” You might deliver all Must-haves on time but ship a product that’s technically complete yet commercially irrelevant. RICE or ICE would have sequenced differently, funding high-value features over merely critical ones.

Third, when continuous delivery makes deadlines fluid. MoSCoW assumes you’re building toward a fixed release date. But modern SaaS products ship continuously, iterating every sprint. In these contexts, Must/Should/Could/Won’t categories feel artificial. RICE or ICE prioritise every sprint’s work by value; MoSCoW sorts by criticality once and then doesn’t adapt gracefully to continuous iteration.

Practical Implementation

Start by gathering all stakeholders—product, engineering, design, business, and any executives with strong opinions. List your backlog objectives and begin the classification debate. For each objective, ask: “If we launch without this, does the product fail to deliver its core promise?” Yes means Must-have. No means it’s Should-have or lower.

Enforce the 30-50% Must-have rule. If more than half your objectives are Must-haves, challenge every classification. Make proponents defend why their objective is existential versus merely important. The friction is the feature—it forces hard thinking about what actually defines “core value.”

Document Should-haves with clear rationale for why they matter but aren’t critical. “Should-have because it significantly improves retention based on competitive analysis” is stronger than “Should-have because it’s important.” Documented rationale enables smarter trade-offs when scope cuts happen.

Explicitly list Won’t-haves with explanations. “Won’t have in v1: paid tiers—deferred until we validate free product-market fit” prevents surprises later. Won’t-haves are your scope contract; treat them as seriously as Must-haves.

Generate your MoSCoW roadmap in RoadmapOne and present it with capacity projections. If you have 12 weeks and 10 Must-haves that total 14 weeks of effort, the math tells the truth: Must-haves won’t all ship on time, or Should-haves need to be cut now to create buffer. MoSCoW makes those trade-offs visible early, not during the final sprint when panic hits.

MoSCoW and Scope Discipline

MoSCoW is scope prioritisation for teams who can’t miss deadlines. It doesn’t optimise for value—it optimises for survival. Use it when the launch date is immovable, scope is negotiable, and stakeholders need crystal-clear commitments about what’s in versus out.

But MoSCoW requires cultural courage. You must be willing to tell executives their favourite feature is a Should-have, not a Must-have. You must enforce bucket limits and resist Must-have inflation. Without that discipline, MoSCoW is just four labels on an unfocused wishlist.

RoadmapOne makes MoSCoW visible at portfolio scale. Classify objectives, set capacity constraints, and let the buckets force honest scope conversations. When the deadline hits and you’ve shipped 100% of Must-haves and 60% of Should-haves, stakeholders knew the commitments from day one. That transparency turns panicked scope fights into calm negotiation, and wishful roadmaps into deliverable plans.

MoSCoW won’t give you the optimal roadmap—but it will give you a roadmap that ships on time with everyone aligned on what “done” means. For fixed-deadline projects, that’s often the only metric that matters.

For more on Objective Prioritisation frameworks, see our comprehensive guide .