MoSCoW Prioritization: How to Stop Everything Being a Must
"Everything on this list is a must." Then nothing is. In this video I take one made-up online shop, a loyalty points scheme with twelve requests all marked must, and sort it with MoSCoW prioritization: the four groups (must have, should have, could have, won't have this time), six ways to stop everything becoming a must (the launch-day test, the reasons the BABOK Guide lists, dependencies, the 60 percent rule, the swap rule), the finished list, and the 5 mistakes to avoid.
Step by step
Prioritizing means choosing what comes first
- Prioritizing isn't asking which requirements matter: to the person who asked, they all do. It's deciding what comes first when time or money runs out. The BABOK Guide calls this task Prioritize Requirements. Example: an online shop wants loyalty points live before its holiday sale.
Explain like I'm 5: the carry-on bag
- Think of packing a small carry-on bag. Passport and phone charger are musts: no trip without them. A warm jacket is a should; you could borrow one. A third pair of shoes is a could. The snorkel set is a won't, this time. Call everything a must and the bag won't close and you miss the flight.
Four ways to prioritize (BABOK)
- The BABOK Guide from the IIBA lists 4 ways to prioritize: grouping (high, medium, low), ranking (first to last), time boxing or budgeting (see what fits the time or money) and negotiation (stakeholders agree). MoSCoW is grouping with 4 named groups. It works best mixed with the other 3.
Before you sort: agree three things
- Before sorting anything, agree 3 things. The deadline: must for what? Here, the first release, live in 8 weeks, before the holiday sale. Who decides: the sales manager has the final say; you run the process. And what each letter means, written down and shared before the meeting.
The request: twelve musts
- The sales manager sends 12 requests for the loyalty scheme, from earning points to gold and silver tiers. All 12 are marked must, so nothing is: the team can't plan, and nobody knows what to drop. MoSCoW sorts them into must have, should have, could have and won't have this time.
M: must have
- A must is something the release can't go without: the launch would be pointless, illegal or unsafe. Test: if it's missing on launch day, do we still launch? Here: earn points, see your points balance, spend points at checkout, and the terms and conditions page finance requires.
S: should have
- A should is important and hurts to leave out, but there's a workaround. Here: an email when points are about to expire (shoppers can check their account page instead), and showing points on each product page, like 'earn 84 points'. If a should has no workaround, it may really be a must.
C: could have
- A could is nice to have, with a small effect if it's left out. Here: birthday bonus points and double points weekends. Coulds are your safety margin: when something runs late, they go first. A healthy list has plenty of them, so the team can hit the date.
W: won't have this time
- Won't have this time means not in this release, as agreed. It doesn't mean never. Here: gold and silver tiers, family sharing, points in the mobile app, and donating points to charity. Writing them down stops the same idea coming back at every meeting and tells people where they stand.
Technique 1: fix the timebox first
- Fix the timebox first, because a must is always a must for something. Here the timebox is 8 weeks, and the team has about 30 days of build work in that time. With no deadline, all 12 wishes feel like musts; 30 days forces a real choice. Write the deadline at the top of the list.
Technique 2: the launch-day test
- For each item, ask: what happens if it isn't there on launch day? Spend points at checkout: points are useless, so must. Expiry email: shoppers check their account page, so should. Birthday bonus: nobody notices in week 1, so could. Gold and silver tiers: shoppers need points first, so won't.
Technique 3: weigh the reasons (BABOK)
- The BABOK Guide lists what to weigh: benefit, penalty (what you lose or pay if it's missing), cost, risk, dependencies, time sensitivity, stability (is it still changing?) and regulatory or policy compliance. The terms page has low benefit but a big penalty, so it's a must.
Technique 4: check the dependencies
- Some requirements need another one first. You can't spend points you never earned, so if spend points is a must, earn points is too. Double points weekends need the earning rules finished first. Rule: a must can never depend on a could. If it does, move the could up or the must down.
Technique 5: the sixty percent rule
- From DSDM, the agile method that made MoSCoW popular: keep musts to about 60% of the effort, no more. Here, 30 days in all: the 4 musts take 18 days (60%), the 2 shoulds 6 days and the 2 coulds 6 days. If musts filled all 30 days, one sick developer would sink the launch.
Technique 6: negotiate with the swap rule
- Get sales and finance in one room. Sales wants double points weekends as a must for the sale; finance worries about the cost of extra points. Swap rule: nothing moves up to must unless something the same size moves down. Sales agrees it stays a could. Write down what was agreed and why.
Worked example: the finished MoSCoW list
- From 12 musts to 4. Must (18 days): earn points, see balance, spend at checkout, terms page. Should (6 days): expiry email, product page points. Could (6 days): birthday bonus, double points weekends. Won't this time: tiers, family sharing, mobile app, charity. Every item keeps its reason.
Confirm it, then keep it moving
- Play the list back to the sales manager and finance to check it, then get the sales manager's sign-off. Priorities shift, so look again when things change. In week 4, earning points runs 3 days late, so the team drops double points weekends, a could, and the date holds.
Where the list goes
- Record each requirement's ID, MoSCoW group, reason and owner: a field on each story in Jira, a single select field in Airtable, or a table on a Confluence page. The tool matters less than the habit. Keep won't haves on the list, ready for the next release.
5 common mistakes
- The 5 common mistakes: everything is a must; no deadline, so every wish feels urgent; treating won't as never; letting the loudest voice win instead of using the same test for everyone; and sorting once and forgetting it. Look again whenever something changes, and protect your coulds.
Recap
- Recap: prioritizing is choosing what comes first when time runs out. MoSCoW has 4 groups: must, should, could and won't have this time. Keep musts honest with a timebox, the launch-day test, the BABOK reasons, dependencies, the 60% rule and the swap rule. Revisit it when things change.
Common mistakes
- Marking everything as a must. If all 12 items are musts, the team can't plan and nobody knows what to drop. Ask the launch-day test of each item against a fixed deadline, and keep musts to about 60% of the effort.
- A must because the boss wants it. A loud voice doesn't make something a must. Weigh every item with the same reasons (benefit, penalty, cost, risk, dependencies) and let the agreed owner make the final call.
- Treating won't as never. Say 'won't have this time' in full and keep those items on the list. Otherwise people fight for every item, and good ideas are lost before the next release.
- Sorting once and forgetting it. Priorities shift as the project moves. Look at the list again when something changes, and keep your coulds unspent, because they're what you drop when work runs late.
When a business analyst uses this
Before a release scope is signed off, a business analyst runs a workshop with the sponsor and the team, tags each item in the requirements log with its MoSCoW group and reason, and checks that musts stay near 60% of the effort. When a build slips, everyone already knows which coulds to drop to keep the date.
Questions people ask
What does MoSCoW stand for?
Must have, Should have, Could have and Won't have this time. Each requirement goes into one of those 4 groups for a set release or deadline.
How do you pronounce MoSCoW?
Like the city, Moscow. The capital letters mark the 4 groups, and the 2 Os are only there so it can be said as a word.
Is MoSCoW a prioritization technique?
Yes. It's a grouping technique: requirements go into 4 named groups instead of being ranked one by one. It works best with a fixed deadline and a real negotiation between stakeholders.
