Open your team’s backlog and count how many items are tagged high priority. If the answer is most of them, what you’re looking at is a labeling habit dressed up as prioritization, one that costs nothing because nothing was ever actually taken away.
MoSCoW prioritization is the fix most often recommended for this. It’s also the framework most often explained in a way that guarantees it won’t work.
Everything Can’t Be a Must (The Real Failure)
Priority overload isn’t a personal discipline failing. Harvard Business Review’s Stop Chasing Too Many Priorities drew on a survey of more than 1,800 executives run by Booz and Company (now Strategy&), which found too many competing priorities to be one of the biggest reasons strategy never became execution. When everything is important, the team quietly decides for itself what gets dropped, and leadership finds out in the retrospective.
Most teams already know three or four prioritization methods. What they lack is a way to enforce a trade-off in a room where the sales director, the engineering lead, and the support manager each arrive certain their item cannot slip. That’s a facilitation problem before it’s a framework problem, and prioritization is a skill you can measure and build, whether you run the meeting or sit in it.
MoSCoW works when you use it to run the room. It fails as a spreadsheet column, which is how nearly every article about it teaches you to use it. For the wider comparison, see our guides to prioritization frameworks and sorting what matters most.
What MoSCoW Actually Is
The four categories, correctly defined
Must Have. The delivery is not viable without it. The DSDM framework supplies the test: ask what happens if this requirement is not met, and if the honest answer is that you would cancel the project, you have a Must Have. Legal deadlines and release-day breakage qualify. Very little else does.
Should Have. Painful to leave out, but there’s a workaround and the release still ships. First thing you pick up if effort frees up.
Could Have. Desirable, small impact if left out. Could Haves exist to be dropped. That’s what they’re for.
Won’t Have (this time). Out of this timebox, agreed and recorded. Consumes zero effort in this window by definition.
Stricter than the tags you already use, which is the point. Our post on priority levels covers how loose labels drift.
Where MoSCoW came from, and why that matters
Dai Clegg created MoSCoW in 1994 while consulting at Oracle, for Rapid Application Development, and it was later donated to DSDM, which made it standard (Wikipedia records the origin; the Agile Business Consortium, which stewards DSDM today, still publishes the effort guidance most articles skip). It was built for fixed-time delivery, where the date is locked and scope is the only variable. Modern explanations strip that context out, which is why they also drop the effort rule below.
”Won’t Have this time” is a deferral, not a rejection
The qualifier does all the work. Won’t Have means not in this timebox, written down, open to reconsideration later, with no date promised. Drop the qualifier and it becomes a rejection bucket, which is when stakeholders stop bringing you real requests and start inflating everything to Must as insurance.
The Rule Nobody Uses: 60/20/20
DSDM attaches an effort-allocation guideline to MoSCoW that most secondary sources mention once and never use: Must Have should account for no more than 60% of the effort in the timebox, with roughly 20% in Should Have and roughly 20% in Could Have.
That 40% sitting in Should plus Could is the contingency. If estimates go wrong, or someone gets sick, or the integration is harder than it looked, you drop from Could first and Should next, and the Must Haves still ship on the date. Won’t Have items sit outside the timebox entirely and take up none of that effort, so they are not a buffer. The buffer is the Should and Could work you were willing to sacrifice.
Used live, the percentage is a forcing function. When the sixth Must Have gets proposed, you don’t say no personally, which is the part that costs you politically. You point at the ceiling: Musts are at 71 points against a cap of 48, so something moves out before this one joins. The number does the refusing.
Use whatever effort unit your team already trusts: story points, ideal days, sizes turned into numbers. Precision doesn’t matter. One shared unit does, and so does totalling the Must column out loud.
How to Run a MoSCoW Session (This Is the Part Everyone Skips)
Who should be in the room
Three roles, and the meeting stays small.
One decision-maker who can say no and make it stick. Without that person, a contested Must Have has nowhere to go and the group defaults to including it. The people closest to the work, because they hold the effort estimates and they will be the ones absorbing an over-stuffed Must column. And one voice representing the customer, so the sort doesn’t become an internal negotiation about whose team looks busy.
Past five or six people, individual sorting turns into performance and the loudest voice wins. If a function needs representation but not a seat, take their input beforehand. That is a delegation decision, and our guide to delegation as a manager covers how to decide what leaves the room.
How to sort, step by step
-
Sort silently first, and do it before the room meets. Everyone gets the full item list, the capacity number, and the 60% ceiling, then assigns M, S, C, or W alone, before anyone speaks. This kills most groupthink and surfaces the items the group already agrees on. Collect the sorts a day early and you can walk in with the Must column already totalled on the board: “the silent sort put us at 71 points of Must against a ceiling of 48.” Now the meeting opens on the overage instead of spending its first hour discovering it, and the room is deciding rather than sorting.
-
Apply the Must-Have test out loud, item by item. For every item someone marked Must, that person answers one question in front of the group: what happens if this isn’t met? Saying it out loud is what makes the test bite; nobody wants to hear themselves claim a release should be cancelled over a settings redesign.
-
Run the 60/20/20 check before you finalize. Total the Must column and compare it to 60% of your capacity. Over that line, the meeting isn’t done.
Timebox the session itself to ninety minutes. A sort that runs longer stops being thorough and starts being avoidance, and the group will begin trading Musts just to get out of the room.
When two stakeholders both call their item a Must
This is the moment the framework is actually for, and no article about MoSCoW ever scripts it. So here is the script.
Maria, a product manager, has SSO from her sales director and a queue refactor from her engineering lead, both marked Must, and both cannot fit under the ceiling.
Maria: “You’re both saying Must. So I need the same sentence from each of you. Finish this: if this doesn’t ship in this release, then what happens? Give me the consequence in something we can count. Revenue, a legal date, or the release doesn’t go out.”
Tom (sales): “If SSO doesn’t ship, the Vantage renewal doesn’t close. That’s 90,000 dollars, and their security review is on the 14th.”
Maria: “Greg?”
Greg (engineering): “If we don’t refactor the queue, exports stay slow.”
Maria: “Slow costing us what, in the next eight weeks?”
Greg: “It’s really important. We’ve been putting it off for two quarters.”
Maria: “Then it’s a Should. Top of the Should column, first in line if we get room back.”
Greg: “So sales wins because they have a number?”
Maria: “You win the moment you give me one. Tell me exports are missing the SLA in two accounts worth 40,000 dollars and we’re having a different conversation. Right now you’ve told me it annoys you.”
“It’s really important” is not a unit. An item whose sponsor can only say that is a Should Have, and hearing that stated plainly, once, does more to fix a team’s prioritization than any template. The test works because it compares two claims against each other in the same currency, not against an abstract standard both sides can bend.
When both sponsors do produce a countable consequence, the test won’t resolve it, and that’s fine. Escalate to the decision-maker and let them choose. Don’t put it to a vote. A vote lets everyone share the blame for a bad call, which means nobody owns it.
One more move before you escalate: ask whether the Must can be made smaller. Not dropped, thinned. Full SSO is 21 points, but SSO for one identity provider might be 8, and that’s what the Vantage contract actually requires. A thin-sliced Must often buys back the room you needed, and the sponsor keeps their deadline.
How to say no and keep the trust
Name the deferral. Out loud, in the room, in the words: “Push notifications are a Won’t Have this time. We’ll look at it again when we scope the next release, and I’m not promising it makes that one either.”
That sentence costs you thirty seconds and buys you the next session. Silently letting an item slide off the board, by contrast, teaches every stakeholder that the way to protect their work is to inflate it. HBR’s The Art of Strategy Is About Knowing When to Say No makes the same argument at the strategic level: the no is the decision. Everything else is just a list.
A Worked Example: Sorting a Real Backlog
Maria’s team has an eight-week release window with a capacity of 80 story points. The 60% ceiling on Must Have is therefore 48 points. Twelve items came into the session.
The silent sort produced seven Must Haves totalling 71 points, which is 89% of capacity: far over the 48-point ceiling, with almost no contingency behind it. The Must-Have test moved three of them.
| Item | Effort | Category | What happens if it isn’t met |
|---|---|---|---|
| Enterprise SSO | 21 | Must | Vantage renewal (90,000 dollars) doesn’t close. Hard date on the 14th. |
| GDPR data-export endpoint | 13 | Must | Regulatory deadline. Non-compliant on Sept 1. |
| Payment retry logic | 8 | Must | Failed charges are lost revenue every day it’s absent. |
| Admin bulk user import | 5 | Must | Two enterprise onboardings are blocked without it. |
| Queue refactor | 8 | Should | Exports stay slow. No countable consequence in this window. |
| Onboarding checklist v2 | 8 | Should | Activation stays flat. Painful, survivable. |
| Slack integration | 8 | Could | Nice to have. Nobody churns over it this quarter. |
| Audit log export | 5 | Could | Requested by two accounts, both have a manual workaround. |
| In-app notification badge | 3 | Could | Cosmetic. |
| Dark mode | 8 | Won’t (this time) | Deferred. Revisit at next release scoping. |
| Settings page redesign | 13 | Won’t (this time) | Deferred. |
| Mobile push notifications | 21 | Won’t (this time) | Deferred. |
The math, which is the whole point:
- Must Have: 21 + 13 + 8 + 5 = 47 points, or 59% of 80. Under the 48-point ceiling by one point.
- Should Have: 8 + 8 = 16 points, or 20%.
- Could Have: 8 + 5 + 3 = 16 points, or 20%.
- Committed total: 47 + 16 + 16 = 79 of 80 points.
- Won’t Have (this time): 42 points of requests, consuming zero effort in this window.
Getting from 71 to 47 in the Must column took exactly three moves, all of them from the tie-break test: queue refactor (8) to Should, onboarding checklist (8) to Should, Slack integration (8) to Could. That’s 24 points out, and 71 minus 24 is 47.
Now look at what the team actually holds. If the SSO work runs 30% over, Maria drops the notification badge and the audit log export, and the release still ships on the 14th with every Must Have intact. That’s what the 40% in Should plus Could bought her. Without the effort rule, all 71 points would have stayed in Must, and the first estimate miss would have taken something load-bearing down with it.
The three Won’t Haves go into the notes with the date of the next scoping session next to them, and Maria sends that list to the room the same afternoon. Nothing disappeared quietly, which is why the same people show up willing to sort again next quarter.
Before your next planning session, check your own prioritization habits. If your Must column has never once been forced under a ceiling, that says more about your process than your team’s. Risely’s free prioritization self-assessment takes a few minutes and shows you where your decisions break down.
A Reusable MoSCoW Template
Six columns. Copy it into whatever you already use.
| Item | Category | Must-Have test answer | Effort | Owner | Revisit moment (Won’t Haves only) |
|---|
The pre-session checklist matters more than the table:
- Invite list capped at five or six. Decision-maker, people closest to the work, one customer voice.
- Effort unit agreed beforehand. One unit, no mixing.
- Capacity on the board, 60% ceiling next to it.
- Everyone sorts silently first, including you.
- Every Won’t Have gets a revisit moment, not a promised date.
If You’re Not the One Running the Session
MoSCoW isn’t only a manager’s tool. Run it on your own workload and it’s where most people get their first real reps.
Take your week the way Maria took the backlog. List what you’re carrying, estimate the hours honestly, then cap your Must column at 60% of the hours you actually have, not the hours in the day. The remaining 40% absorbs the escalation that lands on Thursday. If nothing escalates, you pull a Should forward. That’s a good week.
The harder version is upward. When your manager hands you a list with six things marked critical, “I don’t have time” is a losing sentence, because it sounds like a capacity complaint they’ve heard before.
Bring the arithmetic instead: “These six add up to 60 hours. I have 35. Here’s my read on which three are the real Musts. Which of the other three do you want me to protect, and which are we deferring this cycle?”
That moves the conversation from your capacity to their trade-off, which is where the decision belonged all along. You’re handing back a visible choice, not refusing the work.
Where MoSCoW Falls Short (and What to Use Instead)
MoSCoW is built for a timebox. Take away the fixed window and it loses its teeth, because the mechanism depends on a fixed pool of effort to divide. For year-level bets or an open-ended roadmap, the four buckets flatten distinctions you need to keep.
It also says nothing about sequencing. An item can be a Could Have and still have to ship first because two Musts sit on top of it. You need a dependency map alongside it.
And it doesn’t rank inside a bucket. Ten Must Haves come out as ten equals, which is unhelpful the moment you decide what starts on Monday. When relative order matters, pair it with a scoring model such as RICE or a value-versus-effort matrix. Our roundups of other prioritization techniques and decision-making frameworks cover the options.
The discipline underneath holds regardless. HBR’s 2025 piece on focusing on fewer projects reaches the same conclusion from the portfolio end: organizations that run fewer things finish more of them. MoSCoW is what makes “fewer” survive a room full of stakeholders.
Get Better at the Decision, Not Just the Framework
The framework takes ten minutes to learn. Running it with three senior people who each want their item in the Must column is the skill, and nobody trains for that.
Risely’s free prioritization assessment shows which part of the decision gives way for you: setting the criteria, holding the line under pressure, or communicating the no. To rehearse the hard version first, work through it with Merlin, Risely’s AI coach, on your real backlog.
Then go run the session, and total the Must column out loud.