Cost of delay when the wait is for decisions, not code
Stefan-Iulian Tesoi · · 6 min read
From waiting on decisions, not on engineers. When a coding agent builds an item in an afternoon, the weeks between an idea and its release go on the item being undecided, unspecified or unreviewed. Cost of delay is still the value lost for every week something is not live, so the delay worth pricing now is decision latency.
The arithmetic has not changed. What changed is where the weeks are spent, and most teams still aim their pricing at the stage that stopped being slow.
What is cost of delay when the build is not the delay?
It is the same quantity as before: the value an item would earn or protect each week it is live, lost for each week it is not. Don Reinertsen made it the centre of The Principles of Product Development Flow, with the line "If you only quantify one thing, quantify the Cost of Delay."
The definition never mentioned engineering. It prices time, whatever the time is spent on. For two decades most of that time was build time, so the cost of waiting turned into an argument about engineering capacity: which items make the next sprint and which wait for the one after. A coding agent turns a two-week build into a two-hour one. The weeks between idea and release do not disappear with it. They move upstream and downstream of the build, into stages nobody was pricing.
Where do the weeks actually go now?
Into four waits, and none of them is building. Each is a queue with a person at the front of it:
- Waiting to be decided. The request exists and nobody has said yes or no. It sits in a backlog column that looks like progress.
- Waiting to be specified. Someone said yes, but the acceptance criteria are not written, and an agent cannot start on a sentence.
- Waiting for review. The work came back and a person has to check it against the criteria before it counts.
- Waiting to be released. The change is merged and accepted, and going live is somebody's call.
Our own board shows the shape. On 21 October 2026, three stories for an integration were filed in the morning, and all three reached In Review within three hours. A day later none of them was live. The build was finished. What remained was a release that is one person's decision, and an open product question the work had raised about which repositories unattended runs may merge into. That same week, the list of questions our product owner agent was waiting on a person to answer held 37 entries, and the oldest had waited more than five months.
When the build takes hours, nearly every week an item spends between idea and release is a week spent waiting on a person.
This is the first of the signs of a product ownership gap: the agents are waiting, not the engineers.
How do you put a weekly number on a delay?
Estimate what the item earns, saves or protects per week once it is live, and multiply by the weeks it waits. That is the whole cost of delay calculation. Its value comes from comparing items with each other, not from the precision of any one figure.
- Name the benefit in one unit: revenue, hours saved, churn avoided, risk removed.
- Give a weekly range, low and high, rather than a single number.
- Pick the urgency profile, because it says whether that weekly figure holds, grows or collapses.
- Multiply by the weeks the item is actually waiting on the board, not by a build estimate.
Three cost of delay examples from a typical backlog, at rough figures:
| Item | Value per week | Weeks waiting on a decision | Cost of the wait |
|---|---|---|---|
| Export a customer asked for before renewal | €1,500 of revenue at risk | 3 | €4,500 |
| Fix saving support six hours a week at €50 an hour | €300 | 4 | €1,200 |
| Internal admin screen | €50 | 6 | €300 |
The last column is what a decision should be weighed against. An hour of a product owner's time to settle the first item is cheap next to €4,500. Leaving the third item undecided for another month costs almost nothing, and saying so out loud is a decision too.
Which urgency profile does the item have?
Most items have the long-lived profile where a week of delay loses a week of value and nothing more. The profiles that punish waiting hardest are short-lived opportunities and external deadlines. Black Swan Farming describes four urgency profiles:
| Urgency profile | What a week of delay costs | What changes when agents build |
|---|---|---|
| Long life, peak unaffected | One week of value, no more | The commonest; decision latency costs steadily and quietly |
| Long life, peak affected | A week of value and a lower peak | Competitors build in hours too, so the window closes sooner |
| Short life, peak affected | Most of the value within weeks | Undecided weeks consume the whole life |
| External deadline | Nothing until the last start date, then everything | The last start date moves to days before the deadline |
The first profile is the dangerous one, because nothing about it feels urgent. Each item loses a little every week, and a backlog of fifty of them loses a lot, without any single item ever justifying a meeting.
Which delays can a product team actually remove?
The ones that are queues rather than work: decisions waiting for a meeting, items waiting for criteria, accepted changes waiting for a release slot. Build time was never fully in a product team's hands. Decision latency is.
- Give each open decision an owner and a date, recorded on the item it holds up. A blocker named on the item is a fact; one mentioned in a meeting is a memory. The same rule governs dependencies and sequencing in an agent backlog.
- Sort the undecided list by the cost of the wait, so the item losing €1,500 a week is settled before the one losing €50.
- Write the acceptance criteria as part of saying yes. An approval without criteria moves the item from one queue into the next.
- Release what has been accepted. A change that is finished and not live earns nothing.
Weighted shortest job first needs one adjustment. SAFe defines WSJF as the cost of waiting divided by job duration. When nearly every build takes hours, that denominator stops ranking anything. Divide by the time an item needs from the scarce people instead, the hours of specification and review, and the ranking means something again.
Laimonade records each question its product owner agent is waiting on a person to answer, together with its age, which is how the five-month figure above was counted. It does not answer them. It makes the queue of them visible, and the wider case for running a roadmap around decisions rather than capacity is in the product roadmap when building gets cheap.
Frequently asked questions
Is WSJF still worth using?
Yes, if the denominator measures the scarce resource. Weighted shortest job first divides the cost of waiting by job duration, and duration used to mean build time. With a coding agent building most items in hours, divide by the specification and review time an item needs instead. Dividing by build time ranks items by noise.
What if nobody can estimate the value per week?
Estimate a range and rank on the ranges. A wide range is still more useful than an intuition nobody wrote down, because it can be compared and challenged. When two people's ranges for the same item do not overlap, that disagreement is the decision to have first, and settling it usually tells you what the item is for.
Does a fixed-date item need a cost of delay at all?
Yes, and it is zero until the last date work can start, then the whole value of the item. Record the deadline and the latest start beside it. With an agent building, the latest start is often days before the deadline, so the item should not jump the queue early, and it should not wait for anything once that date arrives.