The MoSCoW method is a prioritisation framework that categorises requirements or projects into four groups: Must have (non-negotiable), Should have (important but not critical), Could have (desirable if resources allow), and Won't have this time (explicitly deferred). In portfolio management, it helps teams make fast, defensible decisions about which initiatives to fund, defer, or drop. Its value lies not in the categories themselves, but in the discipline of assigning every initiative to one of them, leaving nothing in an ambiguous middle ground.
Must haves are the baseline. They are the initiatives or requirements without which the portfolio, programme, or release cannot be considered successful. In portfolio management, Must haves are typically regulatory obligations, contractual commitments, or initiatives directly tied to the organisation’s primary strategic objective for the period.
A common mistake is allowing too many items into the Must have category. If everything is a Must have, the category loses its meaning. A useful test: if this item were removed, would the entire delivery or programme fail? If the answer is no, it is not a Must have.
Should haves are high-value initiatives that the organisation expects to deliver and would be reluctant to drop, but which would not cause the programme to fail if they were deferred. In practice, Should haves are often the items that distinguish a good outcome from a basic one.
In portfolio prioritisation, Should haves are typically the initiatives that score strongly on weighted criteria but do not meet the threshold for Must have. They should be planned in from the start, with the understanding that they may be descoped if capacity is insufficient.
Could haves are desirable but not expected. They are the initiatives that would add value if delivered but would attract no meaningful criticism if deferred. In portfolio terms, these are often efficiency improvements, enhancements to existing capabilities, or exploratory initiatives.
Could haves serve a useful buffer function: they can be pulled into a delivery cycle to absorb spare capacity, or dropped when capacity is tight, without disrupting the core programme.
The Won’t have category is often the most valuable. By explicitly naming what is not in scope for the current cycle, the MoSCoW method prevents scope creep, manages stakeholder expectations, and creates a documented backlog of deferred work for future consideration.
It is important to emphasise ‘this time’. Won’t have does not mean rejected permanently. It means the organisation has made a deliberate decision not to pursue these items in the current period, and that decision is documented and communicated.
Too many Must haves. Apply the failure test rigorously.
Skipping the Won’t have category. Without it, excluded items have no home and resurface as scope creep.
Priorities change; the categorisation should be reviewed each planning cycle.
Without reference to resource capacity, even Must haves can be undeliverable
Undocumented deferrals lead to repeated requests for the same work.
MoSCoW stands for Must have, Should have, Could have, and Won’t have this time. The lowercase ‘o’ letters are added to make the acronym pronounceable. It was originally developed for software requirements prioritisation and is now widely used in portfolio, programme, and product management.
In project management, MoSCoW is used to prioritise requirements, features, or deliverables within a project. It helps project teams and stakeholders agree on what must be delivered for the project to succeed, what should be included if possible, what is desirable but optional, and what is explicitly out of scope for the current delivery.
Yes. MoSCoW is effective at portfolio level for sorting a large backlog of project requests into funded, planned, deferred, and explicitly excluded categories. It works best when combined with defined prioritisation criteria so that category assignments are defensible and consistent across different stakeholders and business units.
MoSCoW stands for Must have, Should have, Could have, and Won’t have this time. The lowercase ‘o’ letters are added to make the acronym pronounceable. It was originally developed for software requirements prioritisation and is now widely used in portfolio, programme, and product management.
Get a personalised walkthrough of Keto AI+, and a business case built around your organisation’s scope, scale, and ambitions.
Most portfolio teams now use AI somewhere in their work. In a 2026 survey of 300 PMO and portfolio leaders, 91% said their organisation is piloting or actively using AI in project delivery. Look at where that AI is used, though, and the picture changes. Reporting and dashboards come first. Only 26% use AI to prioritise or reprioritise work, and only 20% use it for scenario planning.
