UX Glossary | M
MoSCoW analysis
Also: MoSCoW method, MoSCoW prioritisation
A method that sorts requirements into Must, Should, Could and Will not have, so scope is agreed before work starts.
MoSCoW sorts a list of requirements into four buckets: Must have, Should have, Could have and Will not have this time. The lowercase o’s are there only to make the acronym pronounceable. The method was devised by Dai Clegg and became a standard part of DSDM, an agile delivery framework.
What each bucket means
A Must is something without which the release is pointless or unsafe. A Should is important but there is a workaround. A Could is a nice improvement that costs little if dropped. The fourth bucket is the underrated one: writing down what is explicitly out of scope for now saves a great deal of argument later, because a decision exists on paper.
A useful test
Ask of every Must: if we shipped without it, would the product still do its job? If yes, it is a Should. Applied honestly, that question shrinks most Must lists by a third.
Common mistake
Everything ends up as a Must, usually because the loudest stakeholder is in the room and nobody wants the conversation. A list that is all Musts is not prioritised, it is a wish list with a label. Agree the rule for what qualifies before anyone starts sorting.
MoSCoW ranks by necessity, not by value or cost, so it pairs well with an impact-effort matrix or the RICE method when you need an order within a bucket. It is also a fast way to define the scope of an MVP.