What is MoSCoW prioritisation?

The four buckets

Must have — the release is not viable without it. The honest test: would you delay the launch rather than ship without this? If not, it isn't a Must.

Should have — painful to omit, but the release still works. These are the first things to go when the date holds and the estimate doesn't.

Could have — nice, low cost, cut without ceremony.

Won't have (this time) — explicitly out of scope, and explicitly this time. This is the category that does the actual work, because it converts an unspoken assumption into a written decision that stakeholders have seen.

Why it belongs to fixed deadlines

MoSCoW comes from timeboxed delivery. The assumption is that the date is immovable and scope is the variable, so the framework's purpose is to agree the order of sacrifice before you're under pressure. Deciding what to cut at 11pm two days before a launch is how teams cut the wrong thing.

That also explains why it's a poor roadmap tool. It has no notion of value per effort and no way to compare two Must-haves, so a backlog sorted into MoSCoW is barely sorted at all.

The failure everyone hits

Everything becomes a Must have. It happens because Should-have reads as "unimportant" to whoever requested it, and nobody wants their feature demoted in a room. Two defences: cap Musts by effort share, and require a named consequence for each — what specifically breaks if this ships without it. Requirements that can't produce a concrete consequence aren't Musts.

Jira's long accumulation of configurability is what a decade of unchecked Must-haves looks like: every one defensible in isolation, and collectively a product that needs a consultant. Linear's constraint is the same lesson run in reverse.