Skip to content
echogeco
Prioritisation · Frameworks, worked

Cost of delay, worked

Sequence two features by cost of delay divided by duration, check the ratio the long way, and see the order flip when one of them turns out to sit on a fixed date.

Lesson · 9 min · 13 of 59
On this page

RICE and Kano say what a feature is worth; neither says what waiting for it costs, and when a team can only build one thing at a time, waiting is the cost that decides the order. Cost of delay puts a number on it per month, divides by how long the work takes, and sequences a backlog in a way the calendar can check. The two candidates below come out in the opposite order from the one every stakeholder in the room would choose.

Value per month, duration, and the ratio

Reinertsen (The Principles of Product Development Flow) defines cost of delay as the value lost per unit of time that a feature is not live. If a feature will earn or protect $40,000 a month once shipped, every month it is not shipped costs $40,000 — not as an accounting entry but as money that would have existed and does not. His principle F17, the WSJF scheduling principle, says that when durations and delay costs both vary, sequence by cost of delay divided by duration; Arnold (Black Swan Farming) calls the same ratio CD3, cost of delay divided by duration, and that is the name used here.

The two inputs:

  • Cost of delay, in money per month. The hardest number on the sheet and the one worth the argument. It comes from revenue that starts when the feature ships, revenue that stops if it does not, or cost that continues until it does.
  • Duration, in calendar months for the team that will do it. Not effort: a three-person-month item one engineer does alone has a duration of three months; the same item split across three has a duration of one.

Two candidates from the support tool's backlog:

  • X, SSO for the enterprise tier. Sales has $40,000 a month of contracts signed subject to it; they start billing the month SSO is live. The team estimates two months.
  • Y, CSV export. Three tenants' reporting teams have an analytics add-on in their contracts worth $15,000 a month in total, which starts billing when export exists. Half a month.
CD3(X) = $40,000 ÷ 2   = 20   (thousand dollars per month, per month of duration)
CD3(Y) = $15,000 ÷ 0.5 = 30
The smaller, cheaper item wins the ratio: Y delays X by half a month, X delays Y by two.
100%SVG (opens in a new tab)

Pinch to zoom · drag to pan

Y first. The small one with the lower value goes ahead of the big one with the higher value, and the ratio is why: Y delays X by half a month, X delays Y by two.

Check it the long way

The ratio is a shortcut for a sum, and the sum is worth doing once so the shortcut is trusted. Delay cost incurred is each item's cost of delay times the months it waited before going live.

X first:  X waits 2.0 × $40k = $80.0k   Y waits 2.5 × $15k = $37.5k   total $117.5k
Y first:  Y waits 0.5 × $15k =  $7.5k   X waits 2.5 × $40k = $100.0k  total $107.5k

Y first is $10,000 cheaper. The same answer in one line: doing X first makes Y wait X's whole duration, 2 × $15k = $30k; doing Y first makes X wait Y's duration, 0.5 × $40k = $20k. The order that costs less is the order the ratio chose.

The mistake this corrects is "biggest value first". X is worth 2.7× Y, every executive in the room wants it, and putting it first costs $10,000 — small here, because the durations are short, but the error scales with the duration of the big item. A six-month X ahead of a two-week Y costs Y's six months of value, $90,000, to save X two weeks, $20,000.

Four urgency profiles

A single number per month assumes the cost of delay is the same every month — a straight line. The Kanban method's four classes of service (David J. Anderson, Kanban, 2010) name four shapes, and the shape changes the decision more often than the number does.

  • Standard. Linear: each month costs the same. Y is standard — the three tenants pay from whichever month export arrives.
  • Fixed date. Nearly nothing until a date, then a cliff: a regulatory deadline, a contract's go-live clause, a conference. After the date, most of the value is gone.
  • Expedite. Steep from day one and getting worse: an outage, a data leak, a bug that is costing customers now. It goes to the front without a score.
  • Intangible. Flat now, steep later: an eval harness, a test suite, a migration. Cheap to delay this month, expensive to delay for a year.

X turns out not to be standard. The signed-subject-to contracts carry a go-live date — 1 July, nine weeks away — after which the customers may walk, and the $40,000 a month is not delayed but gone, for the year: $40,000 × 12 = $480,000. X sits on a fixed date.

Under that profile, re-run the sequence in weeks, taking a month as four weeks: two months is eight weeks, half a month two.

Y first:  Y done week 2,  X done week 10   → one week past 1 July   → $480k at risk
X first:  X done week 8,  Y done week 10   → Y waits 8 weeks        → 8 ÷ 4 × $15k = $30k
A date is not a value per month. Once X has one, the sequence the ratio chose puts a year of contract behind one week of calendar.
100%SVG (opens in a new tab)

Pinch to zoom · drag to pan

X first, and it is not close. The customers may walk rather than will, so weigh the cliff: X first costs less whenever the chance they walk is above $30,000 ÷ $480,000 ≈ 6%, about one in sixteen; at one in four the expected loss is $120,000, four times Y's wait. The CD3 ranking was correct for the inputs it was given and the inputs were wrong, because X's cost of delay is not $40,000 a month — it is close to zero for nine weeks and then everything. The ratio sequences standard items; the date sequences everything else.

The margin is worth noticing. With 1 July twelve weeks out, Y first lands X at week 10 with two weeks of slack and the $10,000 saving stands. The decision turned on one week of calendar, which is why the date is the first thing to ask for, before the value.

Where the value number comes from

The $40,000 and $15,000 are the whole argument, and in most teams nobody owns them. The sources, in the order to try:

  1. Contracts that start billing on ship, or stop if it slips — the cleanest, and sales has them.
  2. The add-on or price change the feature enables, times the seats expected to take it: the pricing lesson's 12,000 seats × $5 = $60,000 a month for the drafting add-on, scaled by an adoption assumption.
  3. Cost that continues until it ships — the agent-hours the jobs-to-be-done lesson counted, about 9 hours a day returned to one 14-agent tenant.
  4. A range, when there is nothing better: "$10k to $30k a month, and the order is the same anywhere in that range" is an honest input. "$20k" with no source is not.

Treat it as a back-of-envelope estimate: state the assumption, round hard, and check whether the order changes across the plausible range. If it does not, the argument about the exact figure is not worth having. The exercise What the delay costs does this for a launch that slips six weeks, and the FDE's side of the same arithmetic — a customer ask that adds six weeks to a deployment — is in the feature request that adds six weeks.

CD3 is also the framework that knows about the calendar when RICE does not. RICE divides by person-months, which is the right denominator when headcount is the constraint; CD3 divides by calendar duration, which is the right one when the date is. The same item can be cheap in effort and slow in duration — one engineer, part-time, four months — and only the second framework sees it.

In an interview

The prompt is "two features, one team, which goes first", and the interviewer is testing whether you reach for a ratio rather than a feeling. Ask for value per month and duration for each; compute both ratios out loud ("40 over 2 is 20, 15 over half is 30, so the export goes first"); then — and this is what separates the answer — ask whether either item has a date. A candidate who sequences by CD3 and then says "unless SSO's contracts have a go-live clause, in which case the profile is fixed date and SSO goes first regardless" has shown the framework and its limit in one breath.

The mistake that loses points is ranking by value alone — "SSO is worth $40k a month, so SSO" — because it ignores that the small item delays the big one by two weeks and the big one delays the small by two months. The second mistake is the opposite: trusting the ratio past a date. Both are fixed by asking two questions before scoring: how much per month, and is there a cliff.

Check yourself

1. A third item, Z, protects $25,000 a month and takes one month. Where does it go against X (standard, no date) and Y?

CD3(Z) = 25 ÷ 1 = 25, between Y (30) and X (20): Y, then Z, then X. Check the long way. Y–Z–X: Y waits 0.5, Z waits 1.5, X waits 3.5 → 7.5 + 37.5 + 140 = $185k. Z–Y–X: Z 1, Y 1.5, X 3.5 → 25 + 22.5 + 140 = $187.5k. The ratio order is $2,500 cheaper, a margin small enough that either is defensible; the ratio decides because nothing else does.

2. The go-live date for X moves to 1 August, thirteen weeks out. Does Y go first again?

Y first lands X at week 10 with three weeks of slack, so yes — the fixed-date profile is flat until the date, and the date is no longer at risk. The $10,000 saving from the CD3 order returns. Say the slack out loud: a three-week margin on an eight-week estimate is about 40%, which is enough; one week was not.

3. An eval harness has no revenue attached and the team estimates one month. How do you score it against X and Y?

As intangible: cost of delay near zero this month and rising. It does not beat X or Y this quarter. The month before the first AI feature is scheduled, it becomes part of that feature's duration — one month of harness ahead of a six-month feature, and a feature that cannot say when it is done without one — and that is when its ratio is computed, against that feature's value per month.