MoSCoW prioritization

Published 20 October 2026

MoSCoW is a way to agree what a release must include and what can give way when time runs short: each requirement is a Must have, a Should have, a Could have, or a Won’t have this time. The lower-case o’s are only there to make the word pronounceable. Below are the four categories, a worked example, a template, the 60% rule, how to run a MoSCoW session, the common mistakes, and how MoSCoW compares with RICE, Kano and WSJF.

Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement.

— Agile Business Consortium, 2026

Dai Clegg devised MoSCoW in 1994, and the DSDM agile method made it part of its approach (Wikipedia). The Agile Business Consortium, which publishes DSDM, keeps the definitions used below.

The four MoSCoW categories

Category	What it means	Example from a customer portal
Must have	Without it, the release has no point, is unsafe or is not legal	Pay an open invoice by card
Should have	Important, but there is a workaround, even a painful one	A receipt by email — the receipt can be downloaded meanwhile
Could have	Wanted, with less impact if left out; the first to drop when time runs short	Export invoices to CSV
Won’t have this time	Agreed to be out of this release, and written down	Saved cards

In the Consortium’s words, the Must haves “provide the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver”. The rest are not promises either way: “Categorising a requirement as a Should Have or Could Have does not mean it won’t be delivered; simply that delivery is not guaranteed.”

Won’t have this time is not a rejection. It is a decision about this release, recorded so that it stays made: the Consortium notes that recording them “avoids them being informally reintroduced at a later date”.

MoSCoW example

Release 2 of the customer portal from the other templates: 30 days of work available.

ID	Requirement	Priority	Days
`FR-014`	Pay an open invoice by card	Must	14
`NFR-007`	Payment page responds within 2 seconds	Must	4
`FR-016`	Payment reminder after the due date	Should	4
`FR-015`	Email a receipt after payment	Should	2
`FR-021`	Export invoices to CSV	Could	4
`CR-7`	Google sign-in, new customers only	Could	2
—	Saved cards	Won’t, this time	—
`CR-8`	Push notifications	Won’t, this time	—

Must haves take 18 of the 30 days (60%), Should haves 6 (20%), Could haves 6 (20%). If the card payment turns out harder than planned, the CSV export and Google sign-in go first, then the reminder — and the release still does what it is for: letting customers pay invoices sooner.

MoSCoW prioritization template

Copy it into a document or a spreadsheet, one row per requirement. Square brackets are yours to fill in.

MOSCOW PRIORITIES
[project], [release or timebox]
Agreed by:  [name, role], [date]
Capacity:   [n] days

MUST HAVE   ([n] days, [n]% of capacity)
  [ID]  [requirement]  [days]
  Why must:  [what happens without it]

SHOULD HAVE ([n] days, [n]%)
  [ID]  [requirement]  [days]
  Workaround:  [   ]

COULD HAVE  ([n] days, [n]%)
  [ID]  [requirement]  [days]

WON'T HAVE THIS TIME
  [ID]  [requirement]
  Reason:  [   ]
  Revisit:  [release or date]

In a spreadsheet, the columns are: ID, requirement, priority, effort, reason, who agreed it, and the release the priority applies to.

The 60% rule: 60 / 20 / 20

The Consortium recommends keeping Must haves to “typically no more than 60% Must Have effort”, and a pool of Could haves of “typically around 20% Could Have effort”. The Could haves are the contingency: if estimates were wrong, they are what gives, and the date and the Must haves hold.

One commenter, on fixed deadlines: “Flexible scope means you have work to fill up what would go into your buffer that you can launch without if you need to, but would be very nice to have.” (Hacker News, 2018). Another describes it inside a sprint: “So you fill 60% with must have and then with should and could. Then, if you have time over in sprint, you have stuff to do.” (r/agile, 2022).

If the Must haves alone fill more than 60% of the time available, the plan has no room for a single wrong estimate. Cut scope, add time, or move a Must to a later release — before the work starts.

How to run a MoSCoW session

Fix the timeframe first. Priorities belong to a release or a sprint, not to the project forever. The Consortium notes that a requirement can have two priorities at once — one for the project, one for the current increment.
Bring the estimates. Without effort, you cannot check the 60% rule.
Ask the Must question of every Must: what happens if this is not delivered on the date? If there is a workaround, even a manual and painful one, it is not a Must.
Agree who decides. Name the person who settles disagreements, and where it goes when they cannot — before the session, not during it.
Write down the Won’t haves, with the reason and when to look at them again.
Re-prioritise at the end of each release. What was not delivered goes back into the list and gets a new priority for the next one.

The requirements themselves come from the requirements gathering questions; each one can be a user story or a requirement with an ID.

Common MoSCoW mistakes

Everything becomes a Must. One commenter:

MoSCoW sucks and is rarely if ever done properly. EVERYTHING ends up as a M or S and if you have a backlog of 100 items and 50 of them are M’s then you don’t really have prioritisation.

— r/agile, 2022

Another prefers a ranked list “as opposed to the “it’s all a Must item bar this one concession” you tend to see when using MoSCoW” (r/businessanalysis, 2023). The 60% rule is the guard: Musts over 60% means the categories are not doing their job.

No timeframe. “Must” for which release? Without a date, every requirement is a Must eventually.

Won’t haves not recorded. Then they come back in the next meeting as if they were new. A request that returns after being ruled out is a change request, not a reopened discussion — see scope creep.

Mixing priority with requirement wording. “The system must…” in a requirement is not a priority. One commenter’s advice: “it’s not recommended to use ‘should’, ‘could’ or ‘must’ in the requirement so you use ‘Shall’ in all cases as to differentiate from MoSCoW scoring” (r/businessanalysis, 2023).

Using it where it does not fit. One commenter’s view: “It only really works right at the start of a project if you have a very short list of features and stakeholders who can agree with each other.” And: “Once you outgrow MoSCoW, WSJF would work better.” (r/agile, 2022).

MoSCoW vs RICE vs Kano vs WSJF

Method	How it ranks	Best for
MoSCoW	Four groups for one timeframe	Agreeing the scope of a release with a client or stakeholders
RICE	A score: reach × impact × confidence, divided by effort	Comparing many product ideas
Kano	How customers react to having or lacking a feature: must-be, one-dimensional, attractive, indifferent	Deciding what users expect versus what delights them
WSJF	Cost of delay divided by job duration	Ordering a long backlog by economic value
Stack ranking	One ordered list, no ties	A single team picking the next item

RICE comes from Intercom: its author, Sean McBride, notes that “more effort is a bad thing, so it divides the total impact” (Intercom, 2018). The Kano model was developed by Noriaki Kano in the 1980s (Wikipedia). In SAFe, WSJF “is estimated as the relative cost of delay divided by the relative job duration” (SAFe).

MoSCoW answers a different question from the others. RICE, Kano and WSJF order work; MoSCoW draws a line — what this release promises, and what it does not. The two work together: MoSCoW to agree the scope, a ranked list to order the work inside it.

MoSCoW in agile and Jira

In Scrum or Kanban, MoSCoW works at the release level: it decides what the release promises, while the backlog order decides what is built next. In Jira, a custom field or labels with the four values are enough — name the release in the field (“MoSCoW, release 2”) so the priority keeps its timeframe.

Where Specroot fits

This is the problem Specroot works on: priorities kept with the requirements and the version they were agreed on — the Won’t haves included — so that what was ruled out stays ruled out until someone changes it on purpose. Specroot for agencies and consultancies.