MoSCoW Method
The MoSCoW method is a qualitative prioritisation framework used to manage project scope and reach cross-functional alignment. By categorising requirements into four distinct buckets—Must have, Should have, Could have, and Won't have—engineering and product teams can establish clear boundaries, define a Minimum Viable Product (MVP), and maintain delivery velocity under resource constraints.
Core Concepts
The acronym MoSCoW represents four categories of requirements:
| Category | Definition | Impact on Delivery |
|---|---|---|
| Must have | Critical, non-negotiable requirements. Without them, the release or product is a failure. | Mandatory; must be delivered in the current timebox. |
| Should have | Important but not vital requirements. They add significant value but have viable workarounds. | High priority; deferred only if severe constraints arise. |
| Could have | Desirable, low-impact enhancements ("nice-to-haves"). | Low priority; done only if time and budget permit. |
| Won't have | Agreed out-of-scope for the current release. | Deferred; revisited in future iterations. |
The Classification Decision Flow
When evaluating new features or requirements, use the following decision tree to categorise them:
Why CTOs and Tech Leaders Care
1. Guarding Against Scope Creep
Product scope naturally inflates as stakeholders brainstorm. MoSCoW forces stakeholders to negotiate and rank requirements early, preventing engineering from wasting time on low-value "nice-to-haves" that sneak into the backlog.
2. Enabling Fixed-Time, Flexible-Scope Delivery
In the Project Triangle, if time and cost are fixed (e.g., launching a compliance feature before a regulatory deadline), scope must be the variable. MoSCoW gives engineering a clear buffer: if time runs short, the "Could Haves" and "Should Haves" are dropped first, ensuring a safe, on-time launch of the "Must Haves."
3. De-Escalating Trade-Off Discussions
When a sprint or project falls behind, engineers don't need to stop work to ask product managers what to cut. The hierarchy is already established. Engineers can immediately pause work on "Could" or "Should" items to focus on "Must" items, increasing operational autonomy.
Pragmatic Rules of Thumb
- Keep Must-Haves under 60%: A common failure mode is categorising everything as a "Must." A healthy project should have no more than 60% of total engineering effort dedicated to "Must Have" items.
- Maintain a 20% Could-Have Buffer: Ensure at least 20% of your scope consists of "Could Haves." This acts as a release valve for risk and unexpected bugs. If estimates were wrong, you drop the "Could Haves" without impact to the core release.
- Explicitly Document "Won't Haves": Writing down what you won't do is just as important as what you will do. It aligns Sales, Product, and Engineering on release boundaries and prevents hidden expectations.