Don Reinertsen refers to Cost of Delay (CoD) as “the golden key.” CoD is the opportunity cost (in terms of profit and loss) per some unit of time (usually per week) of not achieving something. For example, if achieving a particular outcome will save $50k a week, then a six-week delay in achieving it has a “cost” of $300k. In other words, CoD is the change in lifecycle profit if a piece of work is late (Reinertsen, 2009).
Though Finance does not typically recognize “opportunity” cost, CoD is nevertheless a valuable tool that should not be ignored. It helps us expose and estimate the cost of queues, make smarter tradeoff decisions, and get better at prioritization. Let’s take a quick look at each of these.
Queues
Estimating CoD allows us to expose the otherwise hidden cost of “queue time,” which is the time work spends sitting idle, waiting to be worked on. Work accrues cost whether anyone is working on it or not. Ignoring this is what Reinertsen calls the “Urgency Paradox.” We typically don’t worry about cost until the product team is allocated, at which point everything suddenly becomes urgent (see Arnold, 2015).
This ignores the time already wasted, what Reinertsen calls the “fuzzy front end,” which typically takes up a majority of a product’s lead time (often up to 80%). This includes queue time (“wait waste”) as well as upfront funding and planning activities, some of which are likely non-value-added (map days anyone?) (image adapted from Arnold, 2015).
Allocating work to a product team does not somehow change its CoD—the CoD for queue time and cycle time is the SAME. Since queue time is typically greater than the amount of time work is in process, it is easily the greatest source of cost.
Despite this, we focus most of our effort trying to speed up dev and testing. Instead of focusing on cycle time, we should instead seek to expose and reduce the totality of queue time, a point CoD makes clear.
Tradeoffs
Let’s here define cycle time as the time between starting and completing an activity (cycle time divided by lead time then is a measure of wait waste). It’s important, but not anything we should be obsessing over.
Cycle time is a measure of speed, not agility. As Reinertsen stresses, agility is more the ability to quickly change directions (see Powers, 2016). A good analogy is cheetahs and gazelles. Cheetahs are far faster than gazelles, but rarely catch them, because gazelles can change direction more easily.
Cycle time is a lagging indicator. Reinertsen gives the example of going to Starbucks. The number of people in line is the queue. What we want to know is how long the wait will be. If we ask someone who just got her coffee how long it took, we’re asking about cycle time. The problem is the line (the queue) may have been totally different when she arrived, so what she says won’t be all that helpful.
If instead we knew the baristas’ average velocity (Scrum’s treatment of flow rate) we could apply that to the size of the queue when we arrived in order to predict our cycle time. Since queue size varies more than average velocity it is the best leading indicator of cycle time.
So, what’s this got to do with CoD? Well, we trade off against cycle time constantly, but if we aren’t estimating CoD, then we’re not looking at how much the traded cycle time is worth. Businesses exist to make a profit. Most of the metrics we focus on are proxies for this. When we focus on improving them in isolation, we ignore their interconnections.
The goal is not to monolithically improve a variable, but to optimize tradeoffs. We can’t just focus on reducing queue size, increasing velocity, or eliminating waste. Improving one thing makes others worse. Eliminating variability in product work, for example, also eliminates innovation.
It’s the same with capacity and queues. Idle work generates cost, but since queues in product work are not physical items, they are largely invisible. Because of this, we overestimate the benefit of keeping people busy (capacity utilization). This has unintended consequences.
Reinertsen says the typical dev org operates around 98.5% capacity utilization. Managers assuming factory-like conditions are likely why so many of our dev processes try to keep teams as close to 100% utilization as possible. Product work, however, isn’t like manufacturing. It’s not deterministic, Reinertsen argues, it’s stochastic.
As shown in the diagram below (adapted from Reinertsen, 2014), deterministic models only overload at 100% utilization. This is the mental model many product team managers are probably using. In a stochastic process, however, every time the distance to the right-hand axis is halved the length of the queue doubles. Many managers are blind to this.
If we don’t make end-to-end queues visible and estimate CoD, then we cannot make smart tradeoffs between the cost of queues and the cost of capacity. Ignoring CoD, Reinertsen says, is like having a credit card but not bothering to learn the balance and interest rate. Since, he says, 85% of managers ignore CoD, they try to minimize cost by removing excess capacity, but this is like ensuring it’s always rush hour on a highway.
As shown below, the total cost tradeoff between capacity and queue cost is a U curve. Optimization does not occur at either extreme, which means such managers are hurting their economics. The good news is that since the U curve has a long flat bottom, we do not need to be very accurate in our estimates in order to improve (Reinertsen, 2014).
Some will push back, objecting that CoD is “only estimates.” Why should we be making such decisions based on a priori guesses about how much value something MIGHT create? The problem with this argument is that decisions are already being made based on guesses about value, typically based on assumptions no one is even capturing, discussing, and/or derisking with research.
Anything we can do to improve such guesses over and above intuition will improve our economics. As Reinertsen puts it, estimates do not need to be accurate to be useful.
Often, we only subject what we deem the “biggest” decisions to such analysis, leaving all the rest to HiPPOs—the “highest-paid person’s opinion.” This is what Reinertsen calls the “Pareto Paradox”—there is usually more value and opportunity in the neglected 80% of “little decisions” that are left to HiPPOs and unchecked intuition.
Prioritization
Estimating CoD exposes the hidden cost of queues. It also makes clear that queue cost is dependent on how work is batched and sequenced. Even at the simplest level, CoD clearly demonstrates the economic benefit of constraining WIP and batch sizes. Stage-gate PLCs institutionalize Waterfall and guarantee large-batch handoffs for work, largely negating the value Agile frameworks like Scrum bring to the table (image adapted from Hammerslag, 2014).
Large batch sizes cost more, plain and simple. They result in slower feedback and reduced quality. Annual budget cycles institutionalize large batches at the project level, often starting projects simultaneously.
One of the things CoD makes clear is that this maximizes cost. In the image below (see Reinertsen, 2014), compare the CoD of starting four projects simultaneously, doing them two at a time, and doing them one at a time.
CoD also helps us get better at prioritization. Whatever we choose to complete first, the pipeline is blocked for the rest of the queue until the current work is finished. For the time it takes to complete the current work we will incur its CoD plus that of all blocked items waiting in the queue.
When flow is homogeneous, as it is in manufacturing, there aren’t any cost savings to be had by changing the sequence of work, so it’s fine to use FIFO (first in, first out sequencing). In product work, however, duration and CoD both vary. This means there’s money to be made by getting better at prioritization.
In product work, both FIFO and SJF (shortest job first) prioritization generate unnecessary costs. Often, funding decisions are made based on advocacy, which typically boils down to intuition—somebody higher up got passionate about something.
Reinertsen advocates a weighted shortest job first (WSJF) prioritization, calculated as the estimated CoD per unit of time for an option, divided by its estimated duration (using the unit of time). (This is what Arnold calls “CD3,” or CoD divided by duration.)
When durations are equivalent, prioritization can simply be based on CoD, producing a HVF (highest value first) prioritization. In general, however, the larger the CoD and the shorter the duration, the more something should be prioritized. This can be shown qualitatively as well (from Burns et al., 2016).
To close, Reinertsen famously calls CoD the “golden key,” stating, “If you only quantify one thing, quantify the Cost of Delay” (Reinertsen, 2009).
It’s the “golden key,” he says, because it unlocks so many doors. If we don’t use CoD estimates, he argues, we will have no real sense of how much work is worth per unit of time, which means we really can’t say how much decreases in queue time, cycle time, capacity utilization, batch sizes, or variability are worth to the business.
Tradeoffs between them will suffer.
References
Arnold, J. (2015). How to quantify Cost of Delay. Leankit. Retrieved on February 15, 2017 from: https://leankit.com/blog/2015/11/how-to-quantify-cost-of-delay/.
Burns, M., Reinertsen, D., Matts, C., Arnold, J., Grout, T. & Magennis, T. (2016). Better Backlog Prioritization: From Random to Lifetime Cost of Delay. Retrieved online on February 23, 2017 from: file:///C:/Users/cglambdi/Downloads/Better%20Backlog%20Prioritization.pdf.
Hammerslag, D. (2014). Why you should limit “work in progress.” SolutionsIQ. Retrieved on August 30, 2016 from: https://www.solutionsiq.com/why-you-should-limit-work-in-progress/.
Powers, S. (2016). Adventures with Agile interviews—Don Reinertsen. LinkedIn. Retrieved on February 3, 2017 from: https://www.linkedin.com/pulse/adventures-agile-interviews-don-reinertsen-simon-powers.
Reinertsen, D. (2014). The logic of flow: Some indispensable concepts. Presented at FLOWCON: San Francisco.
Reinertsen, D. G. (2009). The principles of product development flow: Second generation Lean product development. Redondo Beach, CA: Celeritas Publishing.
Charles Lambdin 