If you want a metric that cuts through agile debates fast, it’s this one: Cost of delay. Not velocity. Not story points. Not how many events you’re running.
Cost of delay is plain language for a leadership reality: When value arrives late, you pay for it. Sometimes you pay in lost revenue. Sometimes it’s churn. Sometimes it’s a risk. Sometimes it’s an opportunity cost.
And the frustrating part is this: most organizations feel delayed every day, but they don’t have a clear way to discuss it.
This article gives you a simple way to do that.
If you want the full ROI framing (inputs, assumptions, and a simple business case structure), start here: https://berriaultandassociates.com/resources/agile-transformation-roi/
What “cost of delay” means (no finance degree required)
The cost of delay is the price you pay for waiting.
It answers questions like:
“If this ships one month later, what does that cost us?”
“What’s the impact of leaving this problem unsolved for another quarter?”
“If we keep postponing this decision, what are we trading away?”
The point isn’t to be perfectly precise.
The point is to make trade-offs visible.
Why leaders like cost of delay (even if teams don’t)
Cost of delay is useful because it connects work to outcomes.
It helps leaders:
Prioritize without politics
Stop pretending everything is “urgent”
Justify investment in flow improvements
Explain decisions in a way people can understand
And it’s one of the cleanest ways to discuss agile transformation ROI without getting caught up in framework arguments.
The simplest way to estimate cost of delay (a defensible range)
You don’t need precision theatre.
Use ranges.
Start by choosing a time unit that works for you (per week or per month).
Then estimate three scenarios:
Low (conservative)
Likely (realistic)
High (if things go sideways)
Step 1: Pick the value you’re delaying
Cost of delay usually comes from one (or more) of these buckets:
You don’t need all five. Pick the one that’s most credible for the decision.
Step 2: Estimate the cost per time period
Here are a few simple prompts:
Revenue: “If this launches late, what revenue do we miss per month?”
Retention: “If we don’t fix this, what churn risk continues per month?”
Cost savings: “How many hours/month are we burning until this changes?”
Risk: “What’s the expected cost of the risk per month it remains open?”
Write down your low/likely/high numbers.
Step 3: Multiply by the delay
If the work is delayed by D weeks (or months), then: That’s it.
A simple example (on purpose)
Let’s say you’re deciding whether to invest in reducing a product team's cycle time.
A leader’s “likely” estimate is:
delayed value costs about $50,000/month (missed revenue + support load)
If delivery is consistently delayed by 2 months because of bottlenecks, then:
Cost of Delay approx = $50,000 X 2 = $100,000
That’s $100k of value delayed.
Even if your estimate is off by 30%, you still have a real conversation:
“Is it worth investing $X to reduce this delay?”
“What would we stop doing to make that possible?”
Where cost of delay actually comes from (in most orgs)
Cost of delay isn’t usually caused by teams “working slowly.”
It’s caused by system constraints.
Here are the big ones I see most often:
1) Decision latency
When decisions sit, work waits, or work moves forward with assumptions, creating rework.
If this is showing up for you, here’s the deeper dive: Decision Latency Is Killing Your ROI (link your published post here).
2) Too much WIP
High WIP creates context switching, longer cycle times, and a constant feeling of “busy.”
3) Hidden work (rework and thrash)
Rework is a direct delay multiplier.
If you want the ROI version of this: Cost of Rework: The ROI Leak Nobody Budgets For (link your published post here).
4) Handoffs and approvals
Every handoff is a queue. Every approval step is a potential stall.
5) Priority churn
If priorities change mid-stream, delivery resets. That’s delay disguised as “responsiveness.”
What to do about it (behaviour-first fixes)
This is where most transformations miss.
You can’t spreadsheet your way out of a delay.
You reduce cost of delay by changing behaviours that create delay:
Protect priorities (stop injecting work mid-stream)
Make trade-offs explicit (“If we do this, we’re not doing that”)
Assign decision owners (one throat to choke is harsh language, but the idea is real)
That’s it.