MoSCoW prioritisation gives engineering managers a simple, powerful vocabulary for making trade-off decisions. By categorising work into Must Have, Should Have, Could Have, and Won't Have, teams can align on what truly matters and avoid the trap of treating everything as equally urgent. This guide shows you how to apply MoSCoW effectively in engineering contexts.
Understanding MoSCoW Prioritisation
MoSCoW is a prioritisation technique developed by Dai Clegg at Oracle and widely used in agile and project management. The name is an acronym for four priority categories: Must Have (requirements that are non-negotiable for the release), Should Have (important features that are not critical), Could Have (desirable features that can be deferred), and Won't Have (items explicitly excluded from the current scope).
The framework's strength lies in its clarity. Unlike numeric priority scales where everything tends to cluster at 'high priority,' MoSCoW forces genuine trade-off conversations. When stakeholders understand that Must Have means 'the release fails without this,' they become much more disciplined about what truly belongs in that category.
For engineering managers, MoSCoW is particularly useful during release planning, scope negotiations, and resource allocation discussions. It provides a shared language that product managers, designers, and engineers can all use to discuss priorities without getting lost in subjective debates about importance.
Applying MoSCoW in Engineering Contexts
When applying MoSCoW to engineering work, start by defining clear criteria for each category. Must Have items are those without which the project delivers no value — core functionality, critical security requirements, regulatory compliance features. Should Have items are important but the project can still launch without them. Could Have items are genuine nice-to-haves. Won't Have items are explicitly out of scope for this iteration but may be considered later.
A useful rule of thumb is that Must Have items should represent no more than sixty percent of the total effort in a release. If your Must Have list consumes all available capacity, you have either underestimated the work or overestimated what is truly essential. This buffer ensures that the team has room to handle unexpected complexity and still deliver the most important features.
Involve the entire team in MoSCoW categorisation. Engineers often have valuable insights about technical dependencies that affect priority — a Could Have feature might actually be a Must Have if it is a prerequisite for other critical work. Product managers bring the user and business perspective. The best prioritisation happens when these viewpoints are combined.
- Must Have — the release has no value without these; typically sixty percent or less of total effort
- Should Have — important but the release is still viable without them; plan to include but accept risk of deferral
- Could Have — desirable features that improve the product but can wait for a future release
- Won't Have — explicitly excluded to set clear expectations with stakeholders
MoSCoW for Technical Debt and Infrastructure Work
MoSCoW is especially valuable for prioritising technical work that does not have obvious user-facing value. Technical debt remediation, infrastructure upgrades, and developer tooling improvements all compete for engineering time but can be difficult to prioritise against feature work. MoSCoW provides a structured way to evaluate these investments.
Frame technical work in terms of risk and impact when assigning MoSCoW categories. A database migration might be a Must Have if the current database is approaching capacity limits and will cause outages within the quarter. The same migration might be a Should Have if capacity is sufficient for six more months. The category depends on the consequences of deferral, not on the inherent importance of the work.
Use MoSCoW to negotiate with stakeholders about technical investments. When a product manager pushes back on infrastructure work, showing that it is categorised as Must Have because of specific, quantifiable risks makes the conversation more productive than arguing about the abstract importance of technical health.
Common MoSCoW Mistakes
The most pervasive mistake is putting everything in the Must Have category. When stakeholders are not forced to make genuine trade-offs, they naturally label everything as essential. Combat this by enforcing the sixty percent rule and by asking a pointed question for each proposed Must Have: 'Would we cancel the release if we could not include this?' If the answer is no, it is not a Must Have.
Another common error is neglecting the Won't Have category. Explicitly listing what you will not do is as important as listing what you will do. Won't Have items set clear expectations and prevent scope creep. They also serve as a backlog for future prioritisation — items that are Won't Have this quarter may become Should Have or Must Have in the next.
Treating MoSCoW as a one-time exercise rather than a living document is also problematic. Priorities change as you learn more about the problem, as market conditions shift, and as technical realities become clearer. Review and adjust your MoSCoW categorisation regularly — at minimum at the start of each sprint.
MoSCoW Versus Other Prioritisation Frameworks
MoSCoW works best for scope negotiation within a fixed time frame — deciding what to include in a specific release or quarter. For continuous prioritisation of a product backlog, frameworks like RICE (Reach, Impact, Confidence, Effort) or WSJF (Weighted Shortest Job First) may be more appropriate because they provide a continuous ranking rather than categorical groupings.
The Impact-Effort Matrix complements MoSCoW well. Use the Impact-Effort Matrix to evaluate individual items within a MoSCoW category. For example, among your Should Have items, which ones offer the highest impact for the lowest effort? These are the ones most likely to make it into the release if capacity allows.
Some teams combine MoSCoW with story point estimation to create a more nuanced view. After categorising items, they estimate the effort for each category and compare the total against available capacity. This quantitative check ensures that the Must Have list is not only strategically correct but also practically achievable.
Key Takeaways
- Must Have items should represent no more than sixty percent of total available effort
- Explicitly define Won't Have items to prevent scope creep and set stakeholder expectations
- Ask 'Would we cancel the release without this?' to test whether something is truly Must Have
- Use MoSCoW for technical debt prioritisation by framing items in terms of risk and consequences of deferral
- Review and adjust categorisation regularly as new information emerges
Frequently Asked Questions
- How does MoSCoW differ from simple high/medium/low prioritisation?
- MoSCoW provides clearer definitions and more actionable categories than a generic high/medium/low scale. In most teams, high/medium/low devolves into everything being high priority. MoSCoW's categories have specific, testable definitions — particularly Must Have ('the release fails without this') and Won't Have ('explicitly excluded'). This forces more honest conversations about what is truly essential versus merely desirable.
- Who should participate in MoSCoW prioritisation sessions?
- Include representatives from engineering, product management, and design at minimum. Engineers bring technical dependency and effort insights, product managers bring user and business context, and designers bring usability perspective. For larger initiatives, include relevant stakeholders such as customer support, sales, or compliance. Keep the group small enough for productive discussion — typically six to ten people.
- How often should MoSCoW categories be reviewed?
- Review MoSCoW categorisation at least once per sprint and whenever significant new information emerges. Market changes, user feedback, technical discoveries, and shifting business priorities can all affect which category an item belongs in. The initial categorisation is a starting point, not a permanent assignment. Regular review ensures that your priorities reflect current reality rather than assumptions made weeks or months ago.
Explore Prioritisation Tools
Try our interactive prioritisation tools to apply MoSCoW and other frameworks to your engineering backlog, with templates for stakeholder alignment sessions.
Learn More