MoSCoW is a prioritization method that sorts work into four fixed categories: must have, should have, could have and won't have. It was created in 1994 by Dai Clegg at Oracle UK for the Dynamic Systems Development Method, an early agile framework, and it assumes a fixed delivery deadline. Without a timebox the categories carry no force, because everything can be a must if the date can move.
Whenever you have more candidate features than you can ship in your time window. Most useful at MVP scoping but applicable to any version (V1, V2, sprint planning). The framework is a brutal sorter, not a brainstorming tool.
What MoSCoW is
MoSCoW is a prioritization method that sorts work into four fixed categories: Must have, Should have, Could have and Won’t have. The lowercase o’s exist only to make the acronym pronounceable.
It was created in 1994 by Dai Clegg at Oracle UK, for the Dynamic Systems Development Method, an early agile framework. That origin matters more than it looks, because DSDM assumed a fixed delivery date with variable scope, and MoSCoW is the instrument that varies the scope.
Without a fixed date the method does nothing. If the deadline can move, everything can be a Must, and the four categories become four labels applied optimistically. The discipline is not in the buckets; it is in the question you put to each item: can this version ship without it?
- Fix the date and the goal The precondition
Scope varies, the date does not. Also state what this version exists to prove, or Must has nothing to be measured against.
- Sort into four buckets Discrete, not ranked
Must, Should, Could, Won’t. The fourth is a commitment, not a shelf.
- Apply the cannot-ship-without test Where it bites
If we ship without this, does the version still achieve its goal? Most first-pass Must lists fail this on half their items.
- Cap Must at 60% of capacity The rule teams drop
The remaining 40% is contingency for the work you have not discovered yet. It is not spare.
Why it matters
The most common scope failure is not a missed deadline. It is a feature list where every item carries the same urgency, which is what happens when nobody is willing to make the sorting decision.
That list then meets a fixed date, and the sorting happens anyway, in the last two weeks, under pressure, by whoever is closest to the code. MoSCoW moves the same decision to the start, when it can be made deliberately and communicated.
Anyone who has been in the room for the last-fortnight version knows what it produces. The features that survive are the ones that were nearly finished, not the ones that mattered. Sunk cost does the prioritising, and it is very bad at it.
The version cannot ship without it.
The test If we ship without this, does the version still achieve its goal? If yes, it is not a Must.
Important, and the version survives without it.
The test Painful to leave out, and leaving it out does not invalidate the release.
Nice to have, no effect on the goal.
The test First thing to drop when the estimate slips, and it will.
Explicitly out of scope for this version.
The test Are you willing to say publicly that this is not in V1? If not, you have not sorted honestly.
If you would like to see the 60% rule being ignored at scale, we have data on that, and it is ours. ShipFit proposes a feature set, sorts it into Lean, Balanced and Full packages, and recommends one of them. Here is what a tool built to cut scope actually recommends.
Across 208 AI-generated MVP plans, the average recommended build was 31 weeks and 16 features. The lean option, which the engine never once recommended, averaged 14 weeks.
- Features proposed per idea
- 19.8 mean
- Features in the recommended build
- 16.0 mean
- Recommended build time
- median 30.5 31.4 weeks
- The lean alternative
- recommended 0 times out of 208 14.0 weeks
Sample: n = 208 ideas that reached MVP scoping
What it does not say: A tool that exists to cut scope recommended a seven-month first release, and recommended the same package every single time. Both are worth knowing.
This one is unflattering to us, and we are publishing it anyway. A tool that only reports the numbers making it look good is not reporting numbers.
When to run it
- You have more candidate work than the time window can hold.
- A date is fixed and the feature list is not.
- Stakeholders keep adding "while you are at it" requests mid-build.
- Your last release shipped late and the cutting happened in the final fortnight.
- You are defining an MVP and everything on the list feels essential.
- The date can move, so nothing forces a trade-off. Use ICE scoring →
- You need to sequence the work that survived the cut. Use ICE scoring →
- You do not yet know which problem the release should solve. Use Jobs to be Done →
- You are not sure anyone wants any of it. Use The Mom Test →
The 60% rule
This is the part that most implementations drop, and dropping it is what turns MoSCoW into four labels.
- Must: The ceiling, not the target. Contingency lives in the other 40%.
- Should: Delivered if the build goes to plan.
- Could: The buffer. Dropped first, and dropping it is not a failure.
A team that loads all its capacity into Must has not been ambitious; it has removed the contingency and guaranteed a late release. When that happens the post-mortem usually blames estimation, which is the wrong diagnosis. The estimates were fine. There was nowhere for them to be wrong.
A worked sort
| Candidate feature | Bucket | Effort | Why that bucket |
|---|---|---|---|
| Collect feedback from one channel | Must | 5 | Nothing else works without it. The version cannot deliver its goal. |
| Summarize feedback automatically | Must | 8 | This is the thing being tested. Ship without it and the experiment does not run. |
| Draft a spec from the summary | Must | 6 | The differentiator. Removing it makes the product a worse version of an existing one. |
| Email digest of new feedback | Should | 3 | Valuable, and the version is still usable without it. |
| Slack integration | Should | 4 | Wanted by buyers, not required to prove the hypothesis. |
| Public roadmap page | Could | 4 | Nice to have. No effect on whether the version achieves its goal. |
| Custom fields and tagging | Could | 5 | Requested once. No evidence it changes the decision to buy. |
| SSO and audit logs | Won't | 9 | Explicitly out. The buyer is a founder, not an enterprise security review. |
Must accounts for 43% of the 44 points of capacity here, just inside the 60% cap. That is the check most teams skip: sorting into four buckets feels done, and it is only done once you have added up the Must column and found it fits.
Won’t is a commitment
The fourth bucket is where the method is usually undermined. Teams treat Won’t as “maybe later”, which makes it a shelf rather than a decision, and a shelf provides no protection against the request arriving again next week.
Won’t means: we are willing to say publicly that this is not in this version. If you are not willing to say it out loud, you have not sorted honestly, and the item is really a Should you have not costed.
The test is uncomfortable and it is the point. A Won’t list you would be embarrassed to show a stakeholder is a Won’t list that will not survive contact with one.
Prioritisation in practice: Burbn becoming Instagram
A Must list of one, arrived at by looking at what people used rather than at what the team had planned.
Burbn, which became Instagram · 2010
Cut a feature list down to one feature, and the one was not the plan.
Burbn was a check-in app with plans, points, and photo posting among its features. It was crowded, and it was competing with Foursquare, which was doing check-ins better and earlier.
Systrom and Krieger looked at what people actually used and found it was the photos. They cut everything else, and the surviving product did three things: filtered photos, posted them, liked them.
Instagram launched in October 2010 and was bought by Facebook in April 2012 for about $1bn, with thirteen employees.
- Features in Burbn
- many
- Features in Instagram at launch
- 3
- Employees at acquisition
- 13
What it shows: The cut was possible because there was usage data to cut against. Prioritisation without evidence is just the loudest person in the room choosing, which is the failure mode every scoring framework exists to interrupt.
MoSCoW vs the alternatives
Impact × Confidence × Ease - Strength
- Fast. Three estimates, no research required, usable in a meeting.
- Weakness
- Ignores how many people a change reaches, so a fix for 2% of users can outrank one for everybody.
- Reach for it when
- Growth experiments and early-stage backlogs where everything reaches roughly the same audience.
(Reach × Impact × Confidence) ÷ Effort - Strength
- Adds reach, so scope of audience is priced in. Effort divides rather than multiplying, which penalises large work harder.
- Weakness
- Needs a reach estimate per item, which is the expensive input and often invented.
- Reach for it when
- Mature products with distinct user segments and features of wildly varying scope.
Σ (criterion × weight) - Strength
- Any criteria you like, weighted to match strategy.
- Weakness
- The weights are an argument, and the framework hides the argument inside a number.
- Reach for it when
- Cross-functional decisions where the criteria genuinely differ from team to team.
Four buckets, no arithmetic - Strength
- Forces a binary on the only question that matters for a release: required or not.
- Weakness
- Does not sequence anything inside a bucket.
- Reach for it when
- The first cut. Run it before ICE, then score the Must list.
When it won’t help you
- It does nothing without a fixed date
MoSCoW comes from a method that fixes time and varies scope. If the deadline can move, every item can be a Must and the sort carries no information.
Instead: Fix a date first, even an artificial one. A timebox you chose is still a timebox.
- It does not sequence anything
Four buckets tell you what is in and what is out. They say nothing about what to build first inside the Must list, which is the next question every team has.
Instead: Score the Must list with ICE once the sort is done. MoSCoW first, then ICE.
- The buckets are qualitative and therefore arguable
Two reasonable people put the same feature in different buckets and the framework provides no arbitration. In practice the loudest stakeholder wins, which is the failure it was supposed to prevent.
Instead: Make the version goal explicit and written. Must is measured against that goal, and a stated goal is much harder to argue with than a preference.
- It says nothing about whether the work is worth doing
A perfectly sorted list of features nobody wants is still a perfectly sorted list of features nobody wants.
Instead: Validate the problem before you sort the solution. The sorting is cheap; the building is not.
ShipFit and MoSCoW
ShipFit applies MoSCoW in Stage 5 (What’s V1?). The stage defines the V1 hypothesis, then runs every candidate feature through the cannot-ship-without test, producing three MVP packages (Lean, Balanced, Full) with the Must list explicit in each. Should and Could items are parked in a V2 file with effort tags, so deferred work does not get re-litigated when scope creep arrives later.
Where this sits in the sequence
MoSCoW is the first cut. It comes after you know what the release is for and before you decide what order to build it in.
- Jobs to be Done
Establish what the release has to accomplish for the buyer.
- MoSCoW
Cut the candidate list to what the version cannot ship without.
You are here
- ICE scoring
Sequence what survived the cut.
- Lean validation
Ship it as an experiment and measure what came back.
Further reading
- Dai Clegg & Richard Barker, Case Method Fast-Track: A RAD Approach (1994). Where MoSCoW first appears.
- The DSDM Consortium’s Agile Project Framework, which documents the 60/20/20 allocation and the timebox assumption behind it.
- ICE scoring. What to run on the Must list once the sort is done.
- Lean Startup validation. What the scoped release goes on to test.
- Jobs to be Done. How to establish the goal that Must is measured against.
- The Mom Test. How to be sure the problem is worth scoping at all.
- MVP. What the Must list adds up to.
How to apply MoSCoW
- 1
Fix the date, and write down what this version is for
MoSCoW comes from DSDM, which fixes time and varies scope. If the deadline can move, everything can be a Must and the sort carries no information. State the goal too: Must is measured against what the version exists to prove, and without a stated goal the sorting is a matter of preference.
- 2
List every candidate without filtering
Team wishlist, customer requests, competitor parity items, your own pet features. Do not prioritize while listing. The discipline depends on starting from a full set rather than one that has been quietly pre-curated.
- 3
Sort into the four buckets
Must: the version cannot deliver its goal without it. Should: important, and the version survives without it. Could: no effect on the goal. Won't: explicitly out of scope. The fourth bucket is a commitment, not a shelf.
- 4
Apply the cannot-ship-without test to every Must
If we ship without this, does the version still achieve its goal? If yes, it is not a Must; demote it. Most founders fail this on roughly half their initial Must list, and the demotion is the point of the exercise.
- 5
Add up the Must column and cap it at 60% of capacity
The step teams skip because the sort already feels finished. Estimates are wrong and the remaining 40% is the contingency that absorbs work nobody has discovered yet. A team at 100% Must has not been ambitious, it has removed the contingency and guaranteed a late release.
- 6
Publish the Won't list
Say out loud that these things are not in this version. If you would be embarrassed to show the list to a stakeholder, you have not sorted honestly. A published Won't list is what makes 'while you are at it' answerable with a date rather than a shrug.
Common mistakes
- **Calling everything a Must because cutting hurts.** Forces the Should and Could buckets to be empty, which means the framework isn't doing its job. If your Must list has more than 60% of capacity, you haven't really applied MoSCoW yet.
- **Treating Won't as 'maybe later'.** Won't is a commitment, not a deferral. If you're not willing to publicly say 'this is not in V1,' you haven't sorted honestly. Won't items go in a V2+ file, not a maybe pile.
- **Sorting features without a defined goal for the version.** Must/Should/Could only make sense relative to what V1 is trying to prove. If you haven't defined the goal ('test whether SMB buyers will pay $29/mo for X'), the sort is arbitrary.
- **Letting the team self-sort.** Founders or product leads sort the buckets, ideally with engineering input on effort. If every team member can promote features to Must, the bucket loses meaning.
- **Sorting once and never revisiting.** MoSCoW is meant to be re-applied at every version boundary (V1.1, V2, V2.5). The Should items from V1 become candidates for V1.1's Must list.
How ShipFit operationalizes this
ShipFit applies MoSCoW in Stage 5 (What's V1?). The stage defines the V1 hypothesis, then runs every candidate feature through the 'cannot ship without' test, producing three MVP packages (Lean, Balanced, Full) with the Must list explicit in each. The Should and Could items get parked in a V2 file with effort tags (S/M/L), so deferred features don't get re-litigated when scope creep hits later.
ShipFit runs 55 frameworks across 9 decision stages
MoSCoW is one tool in a bigger toolkit. The full library covers market sizing, buyer discovery, MVP scoping, pricing, and launch.
The Mom Test
Q3Rob Fitzpatrick
Validation question methodology, real interviews, not theater
Jobs-to-be-Done
Q2-Q4Clayton Christensen
Functional, social, and emotional jobs your product fulfills
7 Powers
Q4Hamilton Helmer
Strategic moats: Scale, Network, Counter-positioning, Switching, Brand, Cornered Resource, Process
Van Westendorp PSM
Q6Feature-weighted price sensitivity analysis without guessing
Blue Ocean Strategy
Q4Kim & Mauborgne
ERRC framework: Eliminate, Reduce, Raise, Create
Fake Door Testing
Q7Pre-build behavioral validation with landing pages and apology modals
+ 49 more: TAM/SAM/SOM Analysis, Porter's Five Forces, Market Timing Analysis, Unit Economics (LTV/CAC)...
Frequently asked questions
What does MoSCoW stand for?
How is MoSCoW different from priority numbers (P0, P1, P2)?
Should the Won't list be public?
What's the difference between MoSCoW and ICE scoring?
Can MoSCoW be used outside software development?
How long should the Must list be?
What happens to Should and Could items after V1 ships?
Why does MoSCoW need a fixed deadline?
What is the 60% rule in MoSCoW?
What is the difference between Won't and a backlog?
How many Must features should an MVP have?
Should I use MoSCoW or ICE scoring?
Keep exploring
The 9-step playbook from market verdict to ship-ready spec.
Kim and Mauborgne's framework in plain terms: the strategy canvas, the four actions, the six paths, and the tests that separate a blue ocean from a red one.
ICE scoring ranks ideas by Impact times Confidence times Ease. How to score it honestly, where the arithmetic misleads, and how it really differs from RICE.
Default-prompted AI is a slop machine: agreeable, plausible-sounding, useless for validating an idea. Here's how to use AI for the parts where it actually adds signal, and where to keep it out of the way.
Most founder market research is a TAM slide that nobody believes. The numbers that actually matter are smaller, harder to defend, and tell you whether the market exists for the ten-customer version of your business.
Gross burn lies. Net burn tells you the truth.
The state where a product satisfies a strong market demand from a specific buyer segment such that customer pull on the product exceeds the founder's effort to push it. Coined by Marc Andreessen in 2007 ('the only thing that matters'). Operational measure: 40%+ of active users would be 'very disappointed' if they could no longer use it (Sean Ellis test, popularized by Rahul Vohra at Superhuman in 2018). Below 40%, you don't have PMF yet, regardless of revenue or press.
Fintech idea validation that tests demand, trust, and willingness to pay before you sink months into a regulated build. Forces 9 decisions. Start free.
DimeADozen answers one question (should you build this?) with sourced S-1 and 10-K data for $129 one-time. ShipFit forces 9 sequential decisions with G2 / Trustpilot / Reddit signal, Van Westendorp pricing and exports to 7 coding tools. One decision isn't a build plan.
Ready to make your next product a success?
9 decisions between your idea and a product worth building.