Flocci Projects

Home › Agile answers › What is MoSCoW prioritisation?

What is MoSCoW prioritisation?

MoSCoW sorts requirements into Must have, Should have, Could have and Won't have (this time). Its value is the explicit Won't category, which makes exclusion a decision rather than an omission. Its weakness is that without a cap, everything becomes a Must and the method stops sorting anything.

What each bucket means

Must: the release fails without it. Should: painful to omit but there is a workaround. Could: genuinely nice to have. Won't: consciously excluded from this cycle and recorded so nobody re-litigates it next week. That last bucket is why the method exists.

The discipline that makes it work

Cap Musts at roughly sixty percent of capacity. Without a cap, every stakeholder classifies their own item as a Must and you have re-created an unordered list with more syllables. The cap forces the trade-off conversation the method is supposed to trigger.

MoSCoW versus a ranked backlog

MoSCoW gives four buckets; a ranked backlog gives a total order. Buckets are easier for stakeholder workshops and fixed-date releases; a total order is better for continuous delivery, because 'what is next' has exactly one answer. Many teams use MoSCoW to negotiate scope, then convert the result into a ranked backlog to execute.

Try it on a free Flocci Projects board

Related questions

How do I use MoSCoW in an issue tracker?

Map the buckets onto the priority field or onto labels, then order the backlog within them. In Flocci Projects the four priorities (urgent, high, medium, low) map cleanly, with the Won't bucket handled by leaving items out of the sprint or deleting them.

Is MoSCoW compatible with story points?

Yes, and they complement each other: MoSCoW says what matters, points say what fits. Capping Musts at a fraction of your velocity is where the two meet.

What is the biggest mistake with MoSCoW?

Treating Won't as a rejection instead of a timing decision. Recorded properly, Won't-have-this-time is the most reusable artefact of the whole exercise, because it stops the same argument recurring every planning cycle.

More agile answers