Prioritize With MoSCoW — Requirements Engineering, Part 5

Requirements Engineering · Part 5

A MoSCoW session fails in a way that feels like success. Everyone participates, every requirement gets a label, and the Must list comes back at 140% of what the team can build. Nothing was sorted — the real prioritization now happens in week nine, under pressure, by whoever is loudest.

For why Must inflates and what each label claims, see the MoSCoW method for prioritizing requirements.

Illustrative composite continuing the support-tooling example from Parts 1–4. Figures are illustrative, not measured.

Before You Start

• The candidate set — ours: 31 items for the customer-support refund queue, from the matrix in Part 4.

• Rough sizes — ±50% is fine; you're sorting, not committing.

• Honest capacity — engineer-weeks net of leave, on-call, and support rotation.

• The room — product owner (decides), engineering lead (sizes), one stakeholder who lives with the result, one or two senior engineers.

Don't start if the date is negotiable. MoSCoW without a fixed denominator is a preference survey.

What You'll Build

A labelled set where Must fits inside capacity, every demotion carries a written reason, Won't has re-entry dates, and a validation pass catches a wrong Must list.

Step 1: Fix the Ceiling and Stage the List (30 min, day before)

Write the constraint down before anyone sees the candidates, including you.

• Timebox: 8 weeks — the vendor support cutoff doesn't move

• Capacity: ~18 engineer-weeks (3 engineers, net)

• Must ceiling: ~60% → about 11 engineer-weeks

• Could pool: ~20% → about 3.5 engineer-weeks of sacrificial contingency

Those percentages are DSDM working practice, not mine: the Agile Business Consortium recommends "typically no more than 60% Must Have effort" and "around 20% Could Have effort" — a practitioner convention, not a measured result. Derive it before the session; derived afterwards it's a number people negotiate with. Then stage the candidates: an ID, one sentence, a size each.

Check: you can state the Must ceiling in engineer-weeks, and nothing on the list is a theme. "Better reporting" isn't a candidate — it's several, and it scatters votes.

Step 2: Publish Falsifiable Definitions, Then Vote Silently (15 min)

Hand out the labels as tests, not adjectives:

Label	Claims	Falsified by	Cost if wrong
Must	The release isn't usable without it	What the affected person does on day one without it	Eats contingency, pushes a real Must out
Should	Painful to omit, workaround exists	Naming the workaround and who runs it	Silent Shoulds teach that Should means never
Could	Sacrificial if estimates slip	Asking the owner: cut in week six — escalate?	A Could nobody will surrender isn't contingency
Won't	Not this timebox, re-entry dated	Pointing at the date or trigger	Reads as cancellation, returns as an emergency

Then everyone labels all 31 items independently, in silence — in an open round the room anchors on the first confident voice, not on judgment. Ours came back with 19 Musts against capacity for nine: normal, not a bad room.

Check: all votes are recorded before anyone argued for an item. If discussion started first, re-vote — what you have records who spoke first.

Step 3: Sort by Agreement, Not by Importance (10 min)

Split by vote pattern. Unanimous (ours: 22) — accept in seconds. Split two ways (7) — the real work. Scattered across three or four labels (2) — unclear, not contested.

Both scattered items were split-tender refunds — an order paid partly by card and partly by store credit, with no agreed refund order, because finance and support each assumed the other owned the rule. Not a prioritization question: it goes to the workshop in Part 6.

Check: your remaining time goes only to the split pile, and every scattered item has a named next step elsewhere.

Step 4: Run the Day-One Question on Every Disputed Must (30 min)

Don't ask whether an item is important — that question has no false answer. Ask:

"If this is missing on launch day, do we launch — and what does the affected person actually do that morning without it?"

The longest argument: a supervisor dashboard showing live queue status, twice put in writing as a hard Must. The day-one answer was ordinary: a 7:30 phone round of four team leads, ten minutes, in use for two years. That's fatal to a Must claim, because a Must is defined by the absence of a tolerable path, not the presence of pain.

The contrast that keeps it honest: REQ-006, at-risk refunds sorting to the top, also had a workaround — the twenty-minute morning export from Part 1 — but it stayed a Must, because the second half of the question applies: does that path survive the timebox at real volume? Twenty minutes a day for eight weeks is thirteen hours of the lead's time, and killing that export was the business case for the release.

Check: every surviving Must has a written sentence describing what someone does on day one without it. "It would be really painful" is not an answer.

Step 5: Validate the List Before You Believe It (15 min)

Four checks, written down.

1. Blank-cell count. Musts with no day-one sentence. Ours hit zero only on a second pass — two had "critical for support" recorded, a feeling rather than an action. Any non-zero count is that many unvalidated Musts.

2. Removal test. Remove any single Must: is the remainder still usable end to end? If yes, it isn't in the minimum usable subset. Ours dropped refund-reason analytics.

3. The ratio. Must effort ÷ capacity. Ours: ~10 engineer-weeks ÷ 18 = 0.56.

4. Contingency check. Ask each Could owner whether they'd escalate if it were cut in week six. A yes means a Should is sitting in the Could column.

Check: all four results are on the document. Three of four isn't validated — the one it failed is where the list is wrong.

Step 6: Bound the Won't List (10 min)

Won't have — R1 (revisit at increment 2 planning, 14 Nov)
- Supervisor live dashboard → phone round stays in the runbook
- Per-tier SLA windows      → fixed 5-day rule for all tiers
- Native mobile app         → responsive web only

Every line carries an interim path — what stops the item returning as a mid-sprint "can it also…" (managing requirements changes mid-sprint).

Check: every Won't line has a date or trigger and an interim path. A bare exclusion teaches stakeholders that Won't means never, and next cycle they'll refuse anything below Must.

Step 7: Publish the Decision Record Within the Hour (10 min)

# Refund Queue R1 — Prioritization
Capacity ~18 wk · ceiling ~11 · Must 7 · Should 9 · Could 5 · Won't 4
Validation: 0 blank cells · removal test dropped 1 · ratio 0.56
Decisions
- Supervisor dashboard → Should. Day one: 7:30 phone round,
  ~10 min, two years in use. Revisit at increment 2.
- Split-tender refunds → unlabelled; rule undecided.

Check: someone who missed the session can read the record and say why the most contested item moved. If not, expect to hold that argument again.

You're Done When

• Every Must carries a day-one answer describing an action, and the blank-cell count is zero.

• Must effort ÷ capacity is at or under about 0.6, with a Could pool the owners confirmed they'd surrender.

• Every Won't line has a date or trigger and an interim path, and an outsider can reconstruct the two hardest calls.

Stakeholder acknowledgment is deliberately not on that list; agreement isn't verification.

If This Goes Wrong

Everything came back Must. Expected — nineteen of thirty-one here. Don't lecture the room on discipline; the question they answered has no false answer. Re-run the Step 2 table and the Step 4 question on the Must pile.

Must lands at 90% of capacity after the day-one pass. The play, in order; stop once you're under the ceiling. Split — take the two largest Musts and ask what the thinnest version satisfying the day-one answer looks like; bulk refund approval becomes single-refund approval plus a manual batch path, and half the estimate disappears. Find the interim path — a workaround tolerable for eight weeks specifically makes the item a Should, with that path in the runbook. Sequence — Must for increment 2, dated, keeps the claim intact. Only if all three fail: the scope doesn't fit, and that goes to the sponsor as a choice between the date and the set.

A stakeholder refuses to accept Should. They're usually right about the history — Shoulds sit untouched for three releases and then vanish, so you won't fix the incentive by arguing about a label. Give the item a Should with a named interim path and a dated review, both in the Decisions record where their manager can see them. If they still refuse, escalate that one item with the day-one answer attached.

Common Failure Modes

• Labels used as importance rather than as claims. Every requirement on the list is already important — nobody proposed the unimportant ones. Asked "how important is this?", a room can only answer upward.

• The ceiling derived after the vote. A capacity number produced once people can see their own labels is a number they negotiate with. It has to exist before anyone sees the candidates.

• Discussion before the silent round. The first confident voice becomes the room's framing, and what you record afterwards is who spoke first, not what the room judged.

• A bare Won't list. An exclusion with no date and no interim path teaches stakeholders that Won't means never — and next cycle they refuse anything below Must, which is the inflation you just spent an afternoon undoing.

• Acknowledgment mistaken for verification. A stakeholder confirming they have read the list has told you nothing about whether the Must claims survive the day-one question.

Sources

• Agile Business Consortium, MoSCoW Prioritisation — DSDM Project Framework — minimum usable subset, "Won't have this time," and the 60% / 20% effort guidance in Step 1.

• Dai Clegg and Richard Barker, CASE Method Fast-Track: A RAD Approach (Addison-Wesley, 1994) — the original publication of MoSCoW.

Continue the Requirements Engineering path

• Previous — Part 4: Build a Traceability Matrix

• Next — Part 6: Run a Requirements Workshop