Skip to content
Free tools

Paste your features and categorize them into Must, Should, Could, and Won't Have. Export the result when you're done.

What is MoSCoW Prioritization?

If you've ever sat in a sprint planning meeting where everyone has a different opinion about what's critical, MoSCoW brings order to that chaos. It's one question per feature: does this absolutely need to ship, or can it wait?

The name comes from the first letters of four categories, with filler "o"s to make it pronounceable. Dai Clegg created it at Oracle in 1994, and it's been a staple in agile teams ever since.

  • Must Have - The release fails without these. If a must-have gets cut, you delay the launch.
  • Should Have - Important, but the product still works without them. First candidates for the next cycle.
  • Could Have - Nice additions if the team has spare capacity. Often the first to get dropped when timelines slip.
  • Won't Have - Deliberately out of scope. Writing these down matters because it stops them from creeping back in mid-sprint.

The real value isn't the categories themselves - it's the conversation. When your PM, engineer, and designer have to agree on whether dark mode is a "must" or a "could," you surface assumptions that would otherwise derail the project later.

Frequently Asked Questions

Common questions about MoSCoW prioritization.

Have more questions?

Must have, Should have, Could have, and Won't have. The lowercase "o" letters are just filler to make it pronounceable - they don't mean anything. Dai Clegg coined the term at Oracle in 1994 while working on the DSDM (Dynamic Systems Development Method) project.

MoSCoW works best when you need team alignment in a meeting. It's qualitative and fast - you're sorting features into buckets, not running formulas. Use RICE or ICE when you need data-backed rankings you can defend in a stakeholder review. Many teams use MoSCoW for release planning and RICE for backlog prioritization.

Keep it under 20-30 items per release cycle. Beyond that, people start rushing through decisions and the exercise loses value. If you have a huge backlog, filter out obvious "won't haves" first before running the full exercise.

A common rule of thumb is no more than 60% of your effort budget. If everything is a must have, nothing is. The whole point of the framework is forcing hard tradeoffs, so push back when the list gets top-heavy.

Product, engineering leads, and at least one person who represents the customer perspective - CS, support, or sales. Having diverse viewpoints prevents blind spots. The PM usually facilitates but shouldn't dictate. The real value comes from the debate.

Updated March 2026