Cost-of-delay signals at the requirement level: quick formulas and examples

Most teams argue about priority with adjectives. "This is critical." "That's a nice-to-have." "The CEO wants it." Nobody disagrees out loud, so whoever argues loudest wins the sprint. The whole fight would be shorter if someone could say: this requirement is costing us roughly $1,800 a week while it sits in the backlog, and that one's costing us almost nothing.

That number has a name — cost of delay — and it usually lives at the epic or initiative level, way too high to actually drive sprint-level trade-offs. By the time a program manager computes cost of delay for a quarter-long initiative, the individual requirements inside it have already been sequenced by gut feel.

This post is about pushing requirement cost of delay down to a granularity where it's actually useful: individual requirements, stories, or small feature slices you can sequence in a sprint. The formulas are deliberately lightweight. Spreadsheet math, not a weighted-shortest-job-first certification course. And at the end there are governance rules for when a single requirement's delay cost is big enough to stop being a sprint decision and become a portfolio one.

Why requirement-level is the granularity that actually changes behavior

Cost of delay at the initiative level tells you which bet to fund. At the requirement level, it tells you what to build Monday. Teams conflate these constantly, which is why cost-of-delay workshops produce a nice slide deck and then zero change in actual sequencing.

A typical example: a payments team has an initiative called "Reduce checkout abandonment," valued at maybe $400k of recoverable revenue a year. Fine. But that initiative contains eleven requirements — a saved-card feature, a guest-checkout path, better error messaging on declined cards, address autocomplete, and so on. They do not carry the same urgency. The declined-card messaging might be bleeding real money today, while address autocomplete is a slow, marginal lift. If you only know the initiative's cost of delay, you'll sequence those eleven requirements by whoever's loudest in refinement.

The three numbers you need per requirement

You don't need a model with twelve inputs. Three get you most of the signal:

1. 1
   Value rate — how much value this requirement generates (or protects) per unit of time once it ships. Weekly is the most practical unit.
2. 2
   Decay — whether that value is flat, urgent (decays fast), or time-bound (expires on a date).
3. 3
   Duration — a rough estimate of how long it sits unbuilt, and how long it takes to build.

Cost of delay is the value rate multiplied by the delay. Everything else is refinement on top of that.

Formula 1: Flat cost of delay

`` Weekly CoD = Value per week Total delay cost = Weekly CoD × Weeks delayed ``

If the declined-card messaging fix would recover roughly $1,200/week in otherwise-lost transactions, then every week it sits is $1,200 gone. Delay it six weeks behind other work and you've spent about $7,200 to build other things first. That's not a sunk cost — it's a choice cost, and now it's visible.

Formula 2: Urgency-weighted (value that decays)

Some requirements lose value the longer you wait — a competitor closes the gap, users route around the problem, the moment passes. A simple decay multiplier handles this without pretending to be precise:

A requirement worth $800/week base value but sitting in a "decaying" window gets treated as ~$1,600/week for sequencing. You're not claiming the real number is exactly double. You're encoding this one can't wait into the math so it beats comfortable, flat-value work in the queue.

Formula 3: Deadline / expiry cost

`` Expiry cost = Penalty or lost value if missed Risk-adjusted CoD = Expiry cost × P(miss at current sequence) ``

A requirement with a $50k contractual penalty and a 40% chance you miss the date at current backlog position carries a risk-adjusted cost of delay around $20k. Reorder it so the miss probability drops to 10%, and that number falls to $5k. The delta — $15k — is what the reprioritization is actually worth. That framing tends to land better in a trade-off conversation than "it's compliance, we have to."

A worked example you can drop into a sheet

Take a small B2B SaaS team sequencing six requirements for the next two sprints. Here's the kind of table that makes the argument for you:

That last column — cost of delay divided by build size — is the sequencing signal. It's a lightweight stand-in for WSJF without the ceremony. Higher means "do this sooner." The declined-card fix wins not because it's the biggest feature, but because it's cheap to build and expensive to delay. The CSV export, unglamorous as it is, outranks the enterprise SSO work on this math — which is exactly the kind of counterintuitive result that makes people actually look at the numbers.

Notice what the table does socially: it ends the adjective war. Nobody has to say "I feel strongly about SSO." They can just look at a shared column and move on.

Where the value-rate number actually comes from

The honest problem with all of this is sourcing the value-per-week figure. People hear "cost of delay" and freeze because they think they need a finance-grade model. They don't. A rough number beats no number, as long as everyone agrees on the method for estimating it.

1. 1
   Measured leakage. Declined-card fix? Pull the actual count of failed transactions and multiply by average order value and recovery rate. This is the gold standard when the data exists.
2. 2
   Support-volume proxy. If a requirement would eliminate a recurring ticket category, tickets-per-week × handling-cost gives you a defensible floor.
3. 3
   Churn/contract risk. For retention or compliance work, use the annual contract value at risk × probability, divided across weeks.
4. 4
   Analyst estimate. When nothing else exists, a BA's banded estimate ($500–$1,000/week) is still better than ranking by gut feel. Just record it as an estimate so nobody treats it as measured fact.

“

Label each value-rate with its source (measured, proxy, or estimate) so reviewers can weigh numbers appropriately.

Tie the value number to a source, not a feeling. A requirement whose cost of delay traces back to measured transaction leakage carries weight. One whose number came from a PM's optimism should be labeled as such. Most teams already track the wrong things — we've covered which operational metrics actually drive action rather than sitting on a dashboard.

When a requirement's delay cost should leave the team

This is the governance piece, and it's the part most teams skip entirely. Most requirement-level cost of delay stays a team decision — sequence, build, move on. But some requirements carry a delay cost big enough that letting a single team silently deprioritize them is a portfolio risk.

1. 1
   Compute requirement CoD during refinement, using the formulas above.
2. 2
   Compare against a team threshold. Pick a number — say, any single requirement with risk-adjusted CoD above roughly $15k, or above 20% of the team's quarterly value throughput.
3. 3
   Flag anything over threshold for a lightweight review note. Not a meeting — just visibility.
4. 4
   Aggregate flags monthly. If the same high-CoD requirement has been deferred two reviews running, it escalates into the portfolio investment review automatically.
5. 5
   Attach evidence at escalation. The review doesn't get the raw number — it gets the number plus its source and the deferral history.

That last rule matters more than it looks. A portfolio review receiving naked cost-of-delay numbers will rubber-stamp whatever's largest. One that receives the number alongside its evidence basis can tell the difference between measured leakage and wishful thinking. If you're formalizing this, it connects naturally to portfolio governance that ties investment gates to requirement evidence — the escalation threshold is just the trigger that decides which requirements earn a seat at that table.

A compact flow diagram like this makes it easy to show who does what and when a requirement moves out of team scope.

When this is worth doing — and when it isn't

When it makes sense:

1. 1
   You have more validated requirements than capacity, and sequencing fights are eating refinement time.
2. 2
   At least some requirements have measurable value leakage — payments, churn, support cost, compliance penalties. The math is strongest where money is visibly moving.
3. 3
   You have a portfolio layer above the team that makes funding decisions and keeps starving the wrong things.

When it's a bad idea:

1. 1
   Early discovery, where you don't know if the requirement is even right yet. Cost of delay on an unvalidated requirement is false precision — you're putting a decimal point on a guess.
2. 2
   Tiny teams with a short backlog where everyone already agrees on order. The overhead isn't worth it; just build.
3. 3
   Cultures that will weaponize the numbers. If "my feature has higher CoD" becomes a political cudgel rather than a shared signal, the model makes things worse.

Who should not do this: teams without any value-rate data and no appetite to estimate it. If every number is going to be a pure guess with no agreed method, you'll generate authoritative-looking garbage. Better to fix your measurement basis first — a requirements maturity roadmap gets the traceability and data plumbing in place so the value numbers have something real to point at.

A short real scenario

A mid-sized logistics SaaS — around 40 engineers, four product teams — kept shipping in roughly initiative-value order. The checkout and billing team had a declined-payment retry requirement sitting at the bottom of their backlog for most of a quarter because it looked small and unexciting next to a dashboard redesign everyone was enthusiastic about.

When they finally ran the per-requirement math, the retry logic came out at roughly $1,800–$2,100/week in recoverable failed payments, with a build size under a week. The dashboard redesign? Flat value, maybe $600/week, three weeks of work. The retry fix had been costing them somewhere around $20k over the quarter it sat idle.

They shipped the retry logic the next sprint. Recovered payments climbed by a few thousand a month almost immediately. The dashboard got built about a month later and nobody noticed the delay. The useful outcome wasn't really the one feature though — it was that the team now had a shared column to point at, and the loudest-voice sequencing arguments mostly stopped.

The honest limitation

Requirement cost of delay is a signal, not a verdict. The numbers are rough, the value rates are often estimates, and the urgency factors are deliberately crude.

If two requirements are within 20% of each other on CoD-per-size, the math isn't telling you anything meaningful — sequence them by whatever else matters, like dependency or risk.

What the formulas genuinely buy you: they make the expensive-to-delay requirements visible before they quietly rot in a backlog, and they give you a clean trigger for when a single requirement's delay stops being a sprint call and becomes a portfolio one. Not perfect precision — just enough shared math that the right things get built in roughly the right order, and the genuinely urgent ones don't get buried under whatever happened to be exciting that week.