MoSCoW or WSJF: Prioritising When Everything Is a Must

Five requirements all marked Must, put through MoSCoW's own test and then scored with WSJF: what each method decides, and what it cannot see.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built from a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, no interview. Its requirements register has five rows, REQ-014 to REQ-018, and every one says "Must have, release 1". Section 4.1 of the case calls that a smell and leaves it. This piece runs the five rows through both methods and records what each could decide.

MoSCoW and WSJF answer different questions: MoSCoW asks whether a release can ship without an item, and WSJF asks which of several competing jobs should go first. When every row in a register is a Must, check whether somebody asked the second question and answered it with the first method's labels.

In short

• MoSCoW has a test built in. Put to the five Musts, it moves one acceptance criterion out of the Must column, splits one requirement in two, and finds that two rows are Musts only on a condition.
• WSJF needs four relative estimates per row. Outside the company, every one of them would be a number I chose, so the score would be my opinion expressed as a division.
• The deeper finding: all five rows lead back to one of them. They are one job, and ranking parts of one job against each other is not prioritisation.
• WSJF fits one level up, between the options on the case summary, where jobs really compete. There its logic agrees with the case without a single score.

What does each method actually ask?

The DSDM Project Framework handbook defines Must Have as the "Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver". The DSDM chapter on MoSCoW prioritisation gives four ways to recognise one: no point deploying on the intended date without it, not legal without it, unsafe without it, or no viable solution without it. Then it gives the test: "Ask the question 'what happens if this requirement is not met?'" If the answer is that there is no point implementing the solution, it is a Must.

That question is about one release and one item at a time, and says nothing about order. The Scaled Agile Framework's page on WSJF states the other method in one line: "WSJF is estimated as the relative cost of delay divided by the relative job duration." It names the inputs as "relative user and business value, time criticality, risk reduction and/or opportunity enablement, and job size". That is a question about sequence: of the jobs waiting for the same capacity, which one costs the most to leave waiting, per unit of effort.

The practical difference is the unit. MoSCoW works on anything you can take out of a release. WSJF works on jobs that can be done in any order, each of which delivers value on its own.

The five Musts, as the case has them

REQ-014 Refund on damaged delivery, REQ-015 Escalation ownership, REQ-016 Evidence retention, REQ-017 Condition dispute after payout, REQ-018 Pre-check approves, never refuses. Three of the detail tables add a qualifier after "Must have, release 1":

• REQ-016: "This is a legal gate, not a feature"
• REQ-017: "If money moves earlier, the way back ships with it"
• REQ-018: "It ships with the automation or the automation does not ship"

The last two are conditions. The register already knows these are not free-standing Musts. The index column does not.

Test 1: take each Must out, one at a time

The DSDM question applied literally: remove each row and read the rest of the case to see what breaks. Every "what breaks" entry points at a line already in the published case.

The mapping to DSDM's four reasons is mine. "Unsafe" is the handbook's word, stretched here to financial risk; put REQ-017 and REQ-018 under "cannot deliver a viable solution" if you prefer, and the verdict holds. Three results:

One acceptance criterion is not a Must, and the case already says so. REQ-014 criterion 3 covers partial refunds above the 40 EUR threshold. Section 1.5 lists "whether partial refunds ship in release 1" as undecided, with a fallback written down if the date passes: "Partial refunds drop out of release 1". A criterion with a documented way out of the release is, by the DSDM definition, something the release can ship without. The Must row hides it.

One requirement is two items with two priorities. Section 4.1 names what the case would cut first: "the automation inside REQ-016 criterion 1: a scheduled deletion job becomes a diarised manual deletion for release 1, with the same 90 day rule and the same log." The obligation to delete stays a Must. The job that does it automatically becomes a Could Have. One row, two labels.

Two Musts are conditional, and the condition belongs in the cell. "Must, bound to change 1" tells a delivery manager something that "Must" does not: if change 1 slips, REQ-017 slips with it, and nobody needs to argue about it.

Test 2: score the same five with WSJF

WSJF needs four relative estimates per row. The provenance tags on this site apply to every cell, so here is what the case record can supply for each input.

Twenty cells, and not one can carry [POLICY], [HELP] or [THREADS n=10]. I could fill them in, and the division would produce a tidy ranking out of numbers I made up that evening.

That alone is not an argument against WSJF. Inside the company, with a team estimating together, those cells would hold real relative judgements. The stronger problem is structural, and it would survive perfect data.

Why five rows cannot be ranked against each other

Look back at the "what breaks" column: every row leads to REQ-014.

Ask WSJF's question of REQ-017 alone: what does delaying it cost? If REQ-014 ships without it, the risk section 3.5 describes. If REQ-014 does not ship, nothing. REQ-017 has no value of its own to divide by its size.

WSJF assumes each job delivers value when it is done. REQ-017 and REQ-018 deliver value only as part of change 1, which is why all five rows say Must: they are one change written as five rows. Splitting them is right, because each can be traced and tested. Ranking them against each other is not, because they cannot ship apart.

Where WSJF does fit: between the options

One level up, the case has three options competing for the same capacity, and they are independent jobs. This is the one-page summary, quoted.

B is smaller than C, and it carries what WSJF's third input exists to capture: it enables the measurement that decides whether C is worth doing. A small job that produces the missing number, next to a large job whose value is unmeasured, is the shape the ratio is built for, and it points where the case already went. This is my reading of WSJF's logic, not a calculation; the case never scored its options.

The Must challenge sheet, filled

Test 1 as an artifact, written for this piece. The case as reviewed still says Must on all five rows, and its two reviewers never saw this sheet.

The label "Should, until OQ-05 is decided" is mine. Once the Head of Customer Care decides, it becomes Must or Won't Have this time, and the open question closes.

The Must challenge sheet, blank

Copy it under your register index. Fill the "what breaks" column first and the label last, or the label will write the reason.

Two rules for using it:

• A row whose reason column says "None" is not a Must, however loudly it was asked for.
• A row that is bound to another carries that condition into the priority cell, in words.

What does this change about the argument in the room?

Two moves. First, ask the MoSCoW question literally, row by row, in writing. The requirements register template on this site puts it in fewer words: "Justify Must in four words if challenged." DSDM adds a ceiling: "The safe percentage of Must Have requirements, in order to be confident of project success, is not to exceed 60% Must Have effort." I cannot check it here, because it needs effort estimates and job size is the cell the case leaves [OPEN]. A team with estimates can, and it is a sharper challenge than "too many Musts".

Second, move the ordering question to the level where jobs are independent. If a stakeholder wants their item first, ask whether it can ship alone. If not, rank the larger job it belongs to.

Where this piece is weak

One register of five rows, from one case, by one author. A register of forty rows written by several people would have Musts that genuinely compete, and WSJF at requirement level may earn its keep there.

It judges WSJF by what can be filled from outside, which favours MoSCoW, whose test needs a reading rather than an estimate. And the sheet was not reviewed: I would expect a second reader to push on the "unsafe" mapping, and on whether a criterion inside a Must can carry its own priority.

Where to start

Take your own register and find the row whose priority you would find hardest to defend in four words. Run it through the sheet above. If the "way out" column is filled, you have found a Must that is really a Should, and you found it before a delivery manager did.

The full register behind this piece is on the requirements register template, and the case it comes from is on the case. The feasibility memo that recommends not building it takes the option-level sequencing from above and writes it out as a decision. When two stakeholders want opposite things covers the argument that tends to arrive dressed as a priority dispute.

The scorecard is honest about this gap: its list of what it does not check includes "Whether the change is worth making. Value, priority, sequencing, opportunity cost." No check there will catch a register where every row says Must. The sheet above is the part you run yourself.

All field notes · The portfolio guide · More in Requirements That Survive Review