Cost of Delay

---

Origins

Cost of Delay was formalized in the Agile and Lean product development literature by Don Reinertsen, particularly in The Principles of Product Development Flow¹. Reinertsen's argument is that most teams obsess over development cost while ignoring the much larger and often unmeasured cost of delaying value — the lost revenue, missed opportunity, eroding competitive position, and increased risk that accumulate every week a valuable feature is not in the market.

Joshua Arnold and the Black Swan Farming community² have done the most to make Cost of Delay practical for teams beyond Reinertsen's original quantitative framing. SAFe adopted Cost of Delay as a core component of WSJF, which spread the concept widely — sometimes accurately, sometimes as a number teams produce because their tool asks for one.

What Cost of Delay Means

Cost of Delay is the economic value lost per unit of time by not having a feature, capability, or fix available yet. Most commonly expressed as dollars per week, though dollars per day or per month appear depending on the cadence of the work.

A simple example: a new payment provider integration would save the business $200,000/year in transaction fees. The Cost of Delay is roughly $200,000 / 52 = $3,850 per week of delay. If the team spends 4 weeks building it, the delay cost is about $15,400; if they spend 16 weeks, it's about $61,600. The build cost is the same; the delay cost depends entirely on how long the team takes.

The framing shifts the conversation from "what should we build first?" to "what costs us the most per week we don't have it?"

The Reinertsen Categories

Reinertsen identifies four distinct shapes of Cost of Delay, corresponding to different urgency profiles. Recognizing the shape determines how the item should be sequenced.

Standard (linear)

Cost accumulates at a steady rate per week. Most steady-state operational improvements fit this category — performance optimization, cost reduction, capability extensions. Delay a week, lose a week's worth.

Fixed-date

Cost is low until a hard deadline, then becomes catastrophic. Tax season features, regulatory compliance dates, contractually-committed launches. Whether the feature ships two months early or two weeks early matters less than whether it ships before the date.

Expedite (urgent)

Cost is high right now and only loosely time-sensitive after that. Critical bugs in production, a major customer threatening to churn, security incidents. The team often pulls these items in regardless of normal sequencing rules.

Intangible

Cost is low or unknown in the short term but accumulates and can become serious over a longer horizon. Technical debt, architectural cleanup, monitoring improvements, internal tooling. Often deferred indefinitely because no week's delay seems costly — until the accumulated delay becomes a real constraint.

The four shapes argue for different prioritization treatment. Mixing them all into one ranking misses what each represents.

Estimating Cost of Delay

Cost of Delay is inherently uncertain. Teams that demand precise dollar values up front usually produce confident numbers with no grounding. Teams that refuse to estimate at all leave the entire prioritization conversation to gut feel.

The practical middle ground: estimate roughly but explicitly. For each item, ask a few questions.

• Who benefits from this, and how much per week?
• If we shipped this 3 months later, what would have happened in the meantime?
• What competing forces (competitor, regulation, customer threat) make this more time-sensitive?
• What is the cost of doing nothing for another quarter?

The answers can be order-of-magnitude rather than precise. "About $5K/week" vs. "about $50K/week" vs. "about $500K/week" is usually enough to make the right sequencing decision. Pretending to know whether it's $42K or $47K per week is false precision.

The CD3 Step Toward WSJF

Cost of Delay alone tells you what each item costs to delay. It doesn't yet tell you which item to do first — that depends on how long each takes to do.

Cost of Delay Divided by Duration (CD3) is the prioritization rule: do the item with the highest cost per week of delay, divided by the number of weeks it takes. The intuition: high-cost, short-duration items deliver the most leverage. CD3 is the conceptual predecessor of WSJF.

Common Pitfalls

• False precision: presenting Cost of Delay as a confident dollar figure when the inputs are guesses. Order-of-magnitude is honest; three significant figures usually isn't.
• Treating intangibles as zero: items with hard-to-quantify Cost of Delay (tech debt, monitoring, internal tooling) get systematically deferred because their cost looks small. The cost is often real and large; the difficulty is measurement, not magnitude.
• Confusing Cost of Delay with value: a feature worth $1M shipped at any time is not the same as a feature worth $1M only if shipped before March. The urgency profile is part of the measure.
• Static Cost of Delay: market and business conditions shift. A feature whose Cost of Delay was $10K/week last quarter may be $50K/week now because of competitive moves. Update the estimates.
• Cost of Delay as a single-input prioritization: ranking purely by Cost of Delay ignores duration and risk. Use it as one input alongside others.
• Avoiding the conversation: refusing to estimate at all and reverting to "whoever asks loudest" is a worse choice than imperfect estimation.

Coaching Tips

Estimate Out Loud

Coach teams to make Cost of Delay estimates explicit, even when uncertain. The conversation about how to arrive at the number is where most of the value lives.

Use Order-of-Magnitude

$1K, $10K, $100K, $1M per week is usually enough resolution. Demanding two decimal places of accuracy is how the practice slides into pseudo-science.

Name the Shape

Is this standard, fixed-date, expedite, or intangible? Mixing the four shapes in one ranking buries the urgency profile that should drive sequencing.

Defend the Intangibles

Tech debt, monitoring, tooling — teams often rate these zero because they're hard to measure. Push for a real estimate. Often the cost is far higher than the team admits.

Update When Conditions Change

A competitor's launch, a regulatory shift, a major customer's request — these all change Cost of Delay. Re-estimate items in flight, not just new ones.

Combine with Duration

Cost of Delay alone doesn't tell you what to do first. Divide by job size (CD3 or WSJF) to get the practical prioritization signal.

Summary

Cost of Delay is one of the more consequential ideas in product economics: most organizations dramatically over-weight development cost (which is visible) and dramatically under-weight delay cost (which is invisible until you measure it). Once a team starts thinking in Cost of Delay terms, prioritization conversations become harder to argue against on pure opinion — the question is no longer "is this important?" but "what does it cost us per week not to have it?"

The discipline is to estimate honestly, embrace the uncertainty, and treat Cost of Delay as one input among several. Teams that worship the number produce false precision; teams that refuse to engage with it leave their economics opaque. The middle ground — rough, explicit, updated as conditions change — is where the practice actually pays off.

Back to Prioritization