The change queue had forty-one items on it, and the way we decided what to work on next was embarrassingly simple: whoever emailed my director most recently won. Running network operations at a large enterprise telecom, I watched that queue get reordered by escalation instead of by value for the better part of a year. The team stayed busy. Utilization looked great on the report. And the work that would actually have moved the business kept sliding toward the bottom, because the people who needed it were reasonable enough not to make a scene.

We were optimizing for the wrong thing, and I didn’t have the words for it at the time. The words are cost of delay, and once you have them, you cannot unsee how badly most teams sequence the work in front of them.

What “busy” was hiding

Every prioritization signal we used was a proxy for something other than value. Effort was one: small tasks got picked up because they felt like progress, so the queue filled with quick wins while the expensive, slow, important work aged. Volume was another: the loudest stakeholder got moved up regardless of what their request was worth. And utilization was the quiet villain underneath all of it. When a team is measured on staying fully booked, it will always choose the work that keeps everyone busy over the work that matters, and those are rarely the same thing. I’ve written before about why a fully booked team ships less, not more; the sequencing problem is the same disease wearing a different coat.

The thing none of these signals answered was the only question that counts: what does it cost us, per week, that this specific item is not done yet?

The number nobody in the room could name

That question has a name. Don Reinertsen, whose 2009 book The Principles of Product Development Flow is where most of this thinking traces back, defines cost of delay as the money you lose for every unit of time a piece of work is late. His instruction is blunt: if you only quantify one thing, quantify the cost of delay. It is the number that tells you what a week of waiting is actually worth on any given item.

Here is the uncomfortable part. Reinertsen found that roughly 85% of product managers do not know the cost of delay of the work they are managing, and when he asked people to estimate it by intuition, their guesses varied by a factor of 50 to 1. Fifty to one. That is not a rounding error; that is a room full of smart people who genuinely cannot tell which item is ten times more urgent than another, and are sequencing a portfolio anyway. My change queue was a small version of exactly that. Nobody in the room could have told you what any single item cost us per week, so we defaulted to the signal we could feel, which was who was annoyed.

Value divided by how long it takes

Cost of delay on its own reorders your thinking. Paired with duration, it reorders your queue.

The mechanic is called Weighted Shortest Job First, and the Scaled Agile Framework states it plainly: WSJF is cost of delay divided by job size. You take how much the delay is costing you and divide it by how long the work will take, then you do the highest number first. Joshua Arnold calls the same idea CD3, cost of delay divided by duration. The point of the division is the part managers miss. A moderately valuable job that takes two weeks can, and often should, outrank a hugely valuable job that takes six months, because value delivered sooner starts compounding sooner and value delayed quietly decays.

This is where honest job-size estimates matter, and where most teams fool themselves. If you are going to divide by duration, your duration has to be grounded in what work like this has actually taken you before, not in the optimistic number your team blurts out in planning. That is a separate discipline worth building on its own; I’ve made the case for trusting your history over your estimates precisely because the denominator here breaks if you don’t.

You don’t need exact dollars to start

The objection I hear every time I bring this up is that nobody can put a real dollar figure on most internal work. That is true, and it does not matter as much as you think.

Reinertsen’s 50-to-1 finding cuts the other way too: when your current sequencing is that badly calibrated, even a rough relative score is a massive upgrade. You do not need accounting-grade numbers. You need to rank items against each other on a few dimensions. The framework breaks cost of delay into three pieces you can score on a simple scale: the business value of the thing, its time criticality (does the value drop off a cliff on a deadline, or bleed slowly), and whether it reduces a risk or opens up an opportunity you cannot get otherwise. Score those relatively across your backlog, add them, divide by your best honest read of job size, and sequence by the result.

When I finally did a crude version of this on that change queue, I did not calculate a single dollar. I put the top fifteen items in a spreadsheet, scored each on those three dimensions from 1 to 10, divided by a rough week count, and sorted. Two items that had been languishing near the bottom for months jumped to the top. One of them had been sitting behind a stakeholder who never escalated because escalating was not in his nature. His work was worth more than everything above it. We had been penalizing him for being polite.

Most of the cost is just waiting

There is a second reason cost of delay is worth the trouble, and it is the one that changed how I ran operations for good. Once you start caring about elapsed time, you notice how little of it is actual work.

The metric for this is flow efficiency: the share of an item’s total lead time that anyone spends actively working on it, as opposed to it sitting in a queue. In most knowledge work, teams that have never measured it run around 15% flow efficiency, which means work spends roughly 85% of its life waiting: waiting for a review, an approval, a dependency, a decision. David J. Anderson, who brought Kanban into knowledge work, considers anything above 40% good, and most teams are nowhere near it. When Joshua Arnold’s team mapped this across a $100 million portfolio at Maersk Line, a single feature’s value stream showed weeks of pure waiting against a few days of real effort.

Sit with what that implies. If 85% of the cost of delay is accumulating while the work is parked, then working faster is close to irrelevant. The leverage is in the wait states: the handoffs, the approval steps, the queue your item sits in because the team is too busy to pull it. Cost of delay is what makes that visible, because it puts a price on the parking, not just on the doing. It is the same reason so much of a team’s capacity vanishes into work nobody planned for: the waiting is invisible until you decide to price it.

What changed when we priced the wait

The change on my team was not a new tool or a ceremony. It was one question, asked out loud in every intake conversation: what does a week of delay cost us on this, and how long will it actually take? We could rarely answer the first part in dollars. We could always answer it relative to the other things in the queue, and that was enough to stop letting the loudest voice set the order.

You do not have to build a WSJF spreadsheet next Monday. Start smaller. Take the three items your team is arguing about, and instead of asking which is most important, ask which one costs you the most for each week it waits, divided by how long it takes to finish. You will sequence differently than your gut wanted to, and given how far off the average gut is, that is exactly the point.