Categorizing Requirements into Must Have, Should Have, Could Have, and Won't Have
This skill teaches you how to evaluate each requirement or feature against clear criteria and assign it to the correct MoSCoW category — must have, should have, could have, or won't have — so your team ships what matters most.
To categorize requirements into must have, should have, could have, and won't have, evaluate each item against four criteria: business criticality, user impact, technical dependency, and regulatory obligation. Must haves are non-negotiable for launch. Should haves are important but have workarounds. Could haves are desirable enhancements. Won't haves are explicitly deferred. Apply these definitions consistently using stakeholder input and objective evidence.
Outcome: You can confidently and consistently assign every requirement to the right MoSCoW bucket, producing a prioritized backlog that stakeholders trust and engineers can act on.
Prerequisites
- A gathered list of requirements or features to prioritize
- Basic understanding of the MoSCoW framework and its four categories
- Access to stakeholders or subject matter experts who can validate business impact
- Familiarity with your product's strategic goals and constraints
Overview
Sorting requirements into must have, should have, could have, and won't have categories is the core activity of the MoSCoW prioritization method. Without clear, repeatable criteria for each bucket, teams default to gut feel or political influence — and the resulting prioritization crumbles the moment stakeholders push back. This skill gives you a structured evaluation process so every requirement lands in a defensible category.
The challenge isn't understanding what the four letters stand for. Most teams get that in five minutes. The real challenge is drawing sharp lines between categories when everything feels important. This skill teaches you to apply specific litmus tests — business criticality, workaround availability, regulatory obligation, and user impact — so the boundaries between must have and should have (or should have and could have) become concrete rather than subjective.
When you master this categorization process, you create alignment across product, engineering, design, and business stakeholders. The output feeds directly into MVP scoping, sprint planning, and roadmap construction. It's the foundation skill for every other activity in the MoSCoW framework.
How It Works
MoSCoW categorization works by running each requirement through a decision framework built on four evaluation dimensions: business criticality (does the product fail without it?), user impact (how many users are affected and how severely?), workaround availability (can users or the business achieve the goal another way?), and regulatory or contractual obligation (is there an external mandate?).
The key insight is that the categories are not a spectrum of importance — they represent qualitatively different relationships to the release. A must have isn't just 'very important'; it means the product literally cannot ship or function without it. A should have isn't just 'less important'; it means there's a viable workaround for this release, even though you need it soon. A could have is a genuine enhancement that improves satisfaction but whose absence doesn't degrade the core experience. A won't have is an explicit, transparent decision to defer — not a rejection, but a scoping boundary.
This qualitative distinction is what makes the framework powerful. Rather than arguing about whether something is a 7 or an 8 on a priority scale, you're asking binary questions: 'Can we launch without this? Yes or no.' 'Is there a workaround? Yes or no.' These binary gates make categorization faster and more defensible than numerical scoring systems.
Step-by-Step
Step 1: Prepare Your Requirements List and Context
Before categorizing anything, ensure your requirements list is clean and well-defined. Each item should be specific enough to evaluate — 'improve performance' is too vague, while 'reduce page load time to under 2 seconds on 3G connections' is evaluable. Remove duplicates and merge overlapping items.
Gather the context documents you'll need: the product vision or strategy statement, any regulatory or compliance requirements, contractual obligations, technical architecture constraints, and user research findings. Having these on hand prevents the categorization from becoming a memory test.
Finally, identify the time horizon for your MoSCoW exercise. Are you prioritizing for a single sprint, an MVP release, or a quarterly roadmap? The time horizon directly affects categorization — a feature might be a 'must have' for a Q4 release but a 'won't have' for the current sprint.
Tip: Create a shared document with the requirements list, evaluation criteria definitions, and context links before the session starts. This prevents 30 minutes of setup eating into your prioritization time.
Step 2: Define Your Category Criteria Explicitly
Write down the specific criteria for each category before you start sorting. Generic definitions invite interpretation drift — by requirement #15, 'must have' has subtly expanded to include anything stakeholders feel strongly about.
Here are battle-tested criteria to start with:
- Must have: The product cannot launch, is unusable, is unsafe, or violates a contract/regulation without this. There is no acceptable workaround. Removing this makes the release pointless.
- Should have: This is important and painful to leave out, but the product still works without it. There exists a workaround (even if it's manual, ugly, or temporary). Plan to deliver it soon after must haves.
- Could have: This is desirable and would improve user satisfaction or efficiency, but its absence doesn't cause pain. Include it only if time and budget permit after must and should haves are complete.
- Won't have (this time): This is acknowledged as a valid requirement but is explicitly out of scope for this release. It may be revisited in future iterations.
Post these definitions where everyone can see them throughout the exercise. Refer back to them whenever a categorization debate stalls.
Tip: Add 1-2 real examples from your domain to each category definition. Seeing 'GDPR consent flow = Must Have' and 'Dark mode = Could Have' makes the abstract criteria tangible.
Step 3: Apply the 'Launch Failure' Test for Must Haves
Go through your requirements list and identify the must haves first. For each requirement, ask: 'If we launch without this, does the product fail to deliver its core promise, violate a law, or break a contract?'
Be ruthless. The most common mistake in MoSCoW is overstuffing the must have bucket. A good rule of thumb from Dai Clegg's original framework is that must haves should represent roughly 60% or less of your total effort budget. If your must haves exceed this, you either have too many must haves or your scope is too large for the timeline.
For each candidate must have, apply these secondary checks:
- Is there truly no workaround? (Even a manual, temporary one?)
- Would a significant percentage of users be blocked entirely?
- Is there a legal, safety, or contractual mandate?
If the answer to all three is 'no,' the requirement probably belongs in should have, even if it feels very important.
Tip: Ask the question in reverse: 'What happens if we ship without this?' If the answer is 'users will be annoyed but can still accomplish their core task,' it's not a must have.
Step 4: Separate Should Haves from Could Haves
With must haves identified, take the remaining requirements and split them into should have and could have. This is where most teams struggle because the boundary is less dramatic than the must have line.
The key differentiator is pain and frequency. A should have causes noticeable pain or friction when absent — users will complain, support tickets will increase, or key workflows become significantly slower. A could have, when absent, simply means the experience isn't as polished or delightful.
Apply these questions to each remaining item:
- How many users are affected? High-frequency, broad-impact items lean toward should have.
- How severe is the impact? Significant friction or efficiency loss = should have. Minor inconvenience = could have.
- Is there a reasonable workaround? If the workaround is painful but functional, it's a should have (the pain justifies prioritizing it soon). If the workaround is trivial, it's a could have.
Should haves typically represent about 20% of your effort budget, and could haves another 20%. This gives you a natural buffer — if must haves take longer than expected, could haves get cut first, then should haves if necessary.
Tip: When stuck between should and could, ask: 'Will we get negative reviews or lost customers if this is missing at launch?' If yes, it's a should have.
Step 5: Explicitly Designate Won't Haves
Don't just ignore the remaining items — actively categorize them as won't haves for this release. This step is critical because it transforms an ambiguous backlog into a clear scope boundary.
For each won't have, document why it's deferred and when it might be revisited. 'Won't have this time' is not 'never.' Stakeholders who see their request acknowledged and scheduled for future consideration are far more likely to accept the deferral than those who feel their input was dismissed.
Won't haves often include:
- Features that serve a future market segment you haven't entered yet
- Nice-to-have integrations with low current demand
- Speculative features without validated user need
- Items that depend on infrastructure not yet in place
- Requests from a single stakeholder that don't align with broader strategy
Tip: Create a 'Won't Have (This Time)' section in your roadmap or backlog tool. Revisit it at the start of each planning cycle. This builds stakeholder trust and prevents won't haves from becoming forgotten ideas.
Step 6: Validate the Distribution and Stress-Test Edge Cases
Step back and look at the overall distribution across your four buckets. A healthy MoSCoW split typically follows a ratio close to 60/20/20 for effort across must/should/could haves (with won't haves excluded from the effort calculation since they're deferred).
If your must haves consume more than 60% of available effort, you have a problem. Either you've been too generous with the must have label, or the project scope exceeds your capacity. Go back through the must haves and re-apply the launch failure test more strictly.
Next, stress-test your categorization with edge cases:
- Pick 2-3 items on the boundary between must and should. Present the 'launch without it' scenario to stakeholders. If they accept the workaround, downgrade to should.
- Pick 2-3 should haves and ask: 'If we run out of time, can we live without this for 4-6 weeks post-launch?' If yes, confirm should have. If the delay would cause serious damage, reconsider as must have.
- Verify that no won't haves are actually must haves in disguise — especially compliance or security items that were categorized based on perceived complexity rather than actual necessity.
Tip: Present the categorized list to someone who wasn't in the session — a fresh pair of eyes will quickly spot items that seem miscategorized.
Step 7: Document and Communicate the Categorized Output
The final step is documenting the categorized requirements in a format that's actionable for the team and transparent for stakeholders. For each requirement, record:
- The MoSCoW category
- A 1-sentence rationale for the categorization
- Any dependencies on other requirements
- The estimated effort (if available)
Share this document broadly. The power of must have, should have, could have, and won't have categories is that they're immediately understandable by anyone — executives, engineers, designers, and customers. Use this accessibility to build alignment.
This categorized output directly feeds into defining your MVP scope and building your prioritized roadmap.
Examples
Example: E-Commerce MVP Launch
A startup is building an online marketplace for handmade goods. They have 30 requirements and need to launch in 8 weeks with a small engineering team. Stakeholders disagree on what's essential — the CEO wants social sharing, the CTO wants a recommendation engine, and the compliance officer needs GDPR consent flows.
The team applies the must have, should have, could have, and won't have framework systematically.
Must haves (launch fails without these): User registration and authentication, product listing and search, shopping cart and checkout, payment processing integration, GDPR consent and data handling (legal obligation), basic seller dashboard for order management. These represent about 55% of estimated effort.
Should haves (important, workaround exists): Email order notifications (workaround: sellers check dashboard manually), product reviews and ratings (workaround: launch without social proof initially), basic analytics dashboard for sellers, mobile-responsive design for top 3 screen sizes.
Could haves (nice enhancements): Social media sharing buttons, wishlist functionality, advanced search filters (by material, color, price range), seller promotional tools.
Won't haves (this time): AI-powered recommendation engine (requires significant data first), native mobile app, multi-currency support (launching in one country only), seller subscription tiers.
The CEO's social sharing request lands in could have — users can still share URLs manually. The CTO's recommendation engine is a won't have because it needs purchase data that doesn't exist yet. The compliance officer's GDPR requirement is a clear must have. Each decision is documented with rationale and shared with all stakeholders.
Example: Internal HR Platform Quarterly Release
A mid-size company's HR team is planning the next quarterly release of their internal employee management platform. They've collected 18 feature requests from HR managers, employees, and the legal department. The development team has capacity for approximately 12 weeks of work.
The product owner facilitates categorization using the must have, should have, could have, and won't have criteria with HR leadership.
Must haves: Updated tax withholding calculations (legal deadline in 6 weeks — regulatory must have), single sign-on integration with new corporate identity provider (current auth system being decommissioned — technical must have), annual review form builder for upcoming review cycle (process fails without it). Estimated effort: ~7 weeks (58% of capacity).
Should haves: Improved PTO request workflow (current process works but generates 40+ support tickets/month — high pain, workaround exists), manager dashboard showing team capacity, bulk employee import for upcoming acquisition integration.
Could haves: Employee self-service profile photo upload, org chart visualization, Slack integration for approval notifications.
Won't haves (this time): AI-assisted job description generator, 360-degree feedback module (planned for Q3 after vendor evaluation), employee sentiment survey tool.
The tax calculation update, while unglamorous, is a clear must have due to legal obligation. The PTO workflow improvement is the most-requested feature but gets categorized as should have because the current workflow functions — it's just painful. The team commits to delivering it immediately after must haves.
Best Practices
Always define your MoSCoW categories with specific, written criteria before starting categorization — never rely on the team's intuitive understanding of 'must' vs. 'should.'
Cap must haves at roughly 60% of your available effort budget. If you exceed this, you're either miscategorizing or your scope needs to shrink.
Categorize must haves first by applying the binary 'launch failure' test, then sort the remainder into should, could, and won't have — working from highest to lowest stakes reduces ambiguity.
Document a brief rationale for each categorization decision. This prevents re-litigation in future meetings and helps onboard new team members to the reasoning.
Treat 'won't have' as 'won't have this time' — always communicate that deferred items will be revisited, and actually follow through by reviewing them each planning cycle.
Re-run the categorization whenever a significant constraint changes (timeline cut, budget change, new regulation). MoSCoW categories are tied to a specific release context, not permanent labels.
Common Mistakes
Putting everything in must have because stakeholders insist their features are critical
Correction
Apply the binary 'launch failure' test strictly: if the product can still function and deliver core value without it, it's not a must have regardless of who requested it. Facilitate this by asking stakeholders to describe what happens if the feature ships 6 weeks later — if they can articulate a viable interim state, it's a should have.
Using must have, should have, could have, and won't have as a simple importance ranking (1-4 scale) rather than qualitatively different categories
Correction
Reinforce that the categories represent different relationships to the release, not degrees of importance. A could have might be incredibly valuable — it's just not essential for this specific release to succeed. Train the team on the qualitative definitions before every session.
Leaving the 'won't have' bucket empty because it feels negative or confrontational
Correction
Explicitly populating won't have is one of the most valuable parts of MoSCoW — it creates a transparent scope boundary. Frame it as 'won't have this time' and pair each item with a tentative future date. This turns a potential conflict into a planning conversation.
Categorizing based on effort or feasibility instead of value and necessity
Correction
MoSCoW categorization should reflect how critical the requirement is to the release, not how hard it is to build. A technically complex feature that's required by law is still a must have. Separate the 'what bucket does it belong in?' discussion from the 'can we actually deliver it?' discussion — the latter is a resourcing problem, not a prioritization one.
Doing MoSCoW categorization once and treating the results as permanent
Correction
Requirements shift categories as context changes. A could have might become a must have when a competitor launches that feature, or a must have might become a won't have if the timeline is cut in half. Schedule periodic re-categorization reviews, especially after major scope or constraint changes.
Other Skills in This Method
Building Prioritized Roadmaps from MoSCoW Outputs
How to translate a completed MoSCoW analysis into a phased product or project roadmap with clear release milestones.
Applying MoSCoW to Project and Software Requirements
How to integrate MoSCoW prioritization into requirements gathering workflows for project management and software development.
Resolving Stakeholder Priority Disputes Using MoSCoW
Techniques for handling disagreements when stakeholders push to classify everything as Must-have, including timeboxing and trade-off analysis.
Facilitating MoSCoW Prioritization Workshops with Stakeholders
How to run a structured MoSCoW session that drives stakeholder alignment, manages conflicting opinions, and produces a consensus-based priority list.
Defining MVP Scope Using MoSCoW Categories
How to use the Must-have bucket to draw a clear MVP boundary and negotiate scope with product and engineering teams.
Comparing MoSCoW with RICE, ICE, WSJF, and Other Frameworks
When to choose MoSCoW over quantitative scoring frameworks and how to combine methods for stronger prioritization outcomes.
Frequently Asked Questions
What is the difference between must have and should have in MoSCoW?
A must have means the product literally cannot launch or function without it — there's no workaround. A should have is important and its absence causes pain, but a workaround exists that keeps the product viable for this release. The key test: if you can describe a functional (even if imperfect) product without the feature, it's a should have.
How many requirements should be in each must have, should have, could have, and won't have category?
There's no fixed number, but a healthy effort distribution is roughly 60% must have, 20% should have, and 20% could have of your available capacity. If must haves exceed 60% of effort, you're likely miscategorizing or your scope is too ambitious for the timeline.
What does 'won't have' mean in MoSCoW prioritization?
Won't have means 'won't have this time' — it's an explicit deferral, not a rejection. The requirement is acknowledged as valid but out of scope for the current release. It should be documented with a reason for deferral and revisited in the next planning cycle.
How do I stop stakeholders from putting everything in the must have category?
Apply the binary 'launch failure' test: ask stakeholders to describe what happens if the product ships without that feature. If they can articulate a functional (even painful) interim state, it's not a must have. Also enforce the 60% effort cap — if must haves exceed it, force a re-evaluation of each item against the strict criteria.
Can a requirement change MoSCoW categories over time?
Absolutely. MoSCoW categories are tied to a specific release context, not permanent labels. A could have might become a must have when regulations change or a competitor launches that feature. Re-categorize whenever constraints, timelines, or strategic priorities shift significantly.
How is MoSCoW different from simply ranking requirements by priority?
MoSCoW uses qualitatively distinct categories rather than a linear ranking. Instead of debating whether something is priority #7 or #8, you ask binary questions: 'Can we launch without it?' This makes decisions faster and reduces subjective arguments. For numerical scoring approaches, see how MoSCoW compares with frameworks like RICE and ICE.