Definition
MoSCoW Prioritization
MoSCoW is a prioritization method that sorts requirements into four categories — Must have, Should have, Could have, and Won't have (this time). The capitalized letters form the name; the lowercase o's make it pronounceable. It forces a team to agree explicitly on what is essential versus deferrable, rather than treating every request as equally urgent.
Key takeaways
- MoSCoW sorts requirements into Must have, Should have, Could have, and Won't have (this time) — the capitals spell the name.
- The discipline is in the Won't bucket and the caps: DSDM advises keeping Musts to ~60% of effort so there's contingency to flex under pressure.
- It's categorical, not numeric — fast for stakeholder alignment, but it doesn't rank items within a bucket the way RICE or WSJF do.
- A backlog where everything is a Must hasn't been prioritized; the method's value is forcing explicit trade-offs.
MoSCoW was created by Dai Clegg at Oracle in 1994 and became a core technique of DSDM, an agile delivery framework. Its job is to make scope negotiable and explicit. Must-haves are non-negotiable — without them the release fails or has no value. Should-haves are important but not vital; their absence is painful but survivable. Could-haves are desirable extras included only if time and capacity allow. Won't-haves are agreed out of scope for this cycle, recorded so they aren't silently forgotten.
The discipline lives in the Won't and the caps, not the labels. Anyone can call a feature a Must; the value comes from forcing trade-offs. DSDM recommends keeping Must-haves to roughly 60% or less of effort, with the rest split across Should and Could, so there is genuine contingency to flex when a timebox is under pressure. A backlog where everything is a Must has not been prioritized at all.
MoSCoW is a categorical method, not a numeric one — it groups work into buckets rather than producing a ranked score the way RICE, ICE, or WSJF do. That makes it fast and easy to align stakeholders around, but coarse: it tells you which bucket an item is in, not the order within a bucket. Teams often pair it with a scoring framework to sequence work inside the Must and Should tiers.
Planoda can model MoSCoW as a structured priority field on issues and initiatives, so a release scope reads at a glance and the Won't-have list stays visible instead of vanishing from the backlog.
Related terms
- RICE PrioritizationRICE is a prioritization framework that scores each initiative by Reach (how many people it affects), Impact (how much it moves the needle per person), Confidence (how sure the estimates are), and Effort (the work required). The score is Reach × Impact × Confidence ÷ Effort, producing a comparable number that ranks competing ideas by expected value per unit of work.
- ICE ScoringICE is a lightweight prioritization framework that scores each idea on three factors — Impact (how much it will move the goal), Confidence (how sure you are in the estimate), and Ease (how simple it is to implement) — usually on a 1–10 scale. The ICE score is Impact × Confidence × Ease, giving a fast, comparable number for ranking competing experiments.
- WSJF (Weighted Shortest Job First)WSJF is a prioritization model from SAFe that sequences work for maximum economic benefit by dividing the Cost of Delay by the job's duration or size. The shortest jobs with the highest cost of delay rank first. Cost of Delay itself sums user/business value, time criticality, and risk reduction or opportunity enablement, each scored on a relative scale.
- Kano ModelThe Kano model classifies product features by how their presence or absence affects customer satisfaction, sorting them into five types: Must-be (basics expected by default), Performance (more is better), Attractive (delighters), Indifferent (no effect either way), and Reverse (please some, annoy others). Its core insight is that satisfaction is asymmetric — a missing basic angers users while its presence earns no credit.
- Backlog RefinementBacklog refinement is the ongoing practice of keeping a product backlog ready to work: clarifying items, splitting large ones, adding estimates and acceptance criteria, and re-ordering by priority. Often called grooming, it is continuous rather than a single event, ensuring the top of the backlog is always well-understood and small enough to be pulled into a sprint.