CD3: Cost of Delay Divided by Duration is a prioritisation/scheduling method that maximises the value delivered in a given time period when you have limited capacity. It is particularly useful in environments where a primary constraint of the system is the available time of a relatively fixed or “scarce” resource. This matches product development very well, because of the communication, collaboration and coordination overheads, which constrain our ability to increase capacity.
CD3 is one specific form of the “WSJF – Weighted Shortest Job First” queuing method. We could choose weight by other things (risk, stakeholder importance, length of time waiting, etc). In the case of CD3 we are weighting by Cost of Delay. (Saying “Cost of Delay Divided by Duration” more than a few times get rather tiring, so to ease communication we can shorten this to CD3.)
One of the benefits of CD3 is that it enables us to use a common measure to compare opportunities with different value and urgency, and where the duration differs. CD3 optimises the Return on Investment by minimising the total Delay Cost incurred, given a set of potential options. In most product development settings, capacity is relatively inflexible and constraints on scaling beyond certain limits. Because of this, even a very rough understanding how long the pipeline is likely to be blocked for is quite valuable information – it can change the order in which we decide to schedule work. Because CD3 uses Duration on the denominator, it also has the benefit of encouraging the breakdown of work into smaller batches. Breaking down work and delivering in smaller batch sizes is one of the easiest, cheapest and most effective improvements we can make in terms of getting more value, faster flow and better quality.
When using CD3, the priority order of features (or initiatives/projects) is determined by dividing the estimated Cost of Delay by some estimate of duration: the higher the resulting score, the higher the priority.
Comparing CD3 to other prioritisation methods:
Let’s use an example to demonstrate how and why CD3 improves Return on Investment. Consider the following three features:
|Cost of Delay||Duration||CD3 Score|
|Feature A||$1,000/week||5 weeks||200|
|Feature B||$4,000/week||1 week||4,000|
|Feature C||$5,000/week||2 weeks||2,500|
Using these three features we can look at the impact to two alternatives to how we might schedule them. We could choose to work on and deliver these features one at a time in the order they arrived. A, then B, then C. (This is called First In, First Out. It is a common scheduling approach in manufacturing). After all, the person asking for Feature A will have been waiting for the longest time so we really should serve them first. Then B, and then C.
For the 5 weeks we are working on Feature A we incur the Cost of Delay of all three features: $5,000/wk + $4,000/wk + $1,000/wk. This adds up to $10,000/week times 5 weeks giving us a total Delay Cost incurred so far of $50,000.
We then move on to developing Feature B. For the 1 week this takes us to deliver we incur the Cost of Delay of Features B and C: $4,000/week + $5,000/week = $9,000/week. So the Delay Cost is an additonal $9,000, bringing us to a total of $59 worth of Delay Cost incurred so far.
At last, we can start working on Feature C. incuring the Cost of Delay of C during it’s development of $5,000/week for the two weeks it takes to build Feature C. This is another $10,000 of Delay Cost to add to our previous of $59,000 for a total of $69,000 Delay Cost incurred.
Or, use CD3: Cost of Delay Divided by Duration
Let’s consider another way of processing these Features. If we work on the features based on whichever has the highest CD3 score we would do Feature B first, followed by Feature C, and finally Feature A.
For the 1 week we are working on Feature B we incur Cost of Delay of $(4k+5k+1k)/week. Delay Cost = $10,000
For the 2 weeks we are working on Feature C we incur Cost of Delay of $(5k+1k)/week. Delay Cost = $12,000
For the 5 weeks we are working on Feature A we incur Cost of Delay of $1k/week. Delay Cost = $5,000
Total Delay Cost using CD3 is $27,000 a 61% decrease in the Delay Cost.
As you can see, using CD3 to order your backlog and prioritise features or projects can have a big difference.
Why bother with Duration?
Many people with a tech background seem to be very afraid of estimates. I understand and empathise with their views, whilst not prescribing quite the same solutions. Of course in some cases estimates have been abused, so it is understandable that they want to avoid them.
I also hear people say that there is “no correlation” between size and duration. What I haven’t seen though, is any study that proves this (show me the R-squared, please). For my own “anecdata”, I have seen some useful correlation. Not perfect precision, of course, but more than sufficient accuracy for me to recommend not ignoring data that (for most organisations I’ve worked with) already exists and is (rightly or wrongly) part of the fabric of the organisation.
While I may seek to reduce reliance on these estimates, I’d rather leave it intact and show them how to replace what they have been doing with much more effective methods to achieve the outcomes they are looking for. Either way, CD3 works perfectly well enough with noisy inputs on the denominator. Is it perfect? No, of course not.
I also attempt to answer some challenges people sometimes raise with using Duration in this article, which you may find helpful.
In summary, CD3 is useful in environments where the defining constraint of the system is the available time of a scarce resource. In Product Development, this would be the group of men and women who can turn rough ideas into something of value for the organisation. If your system has other defining constraints, then CD3 is not for you. You may be able to safely ignore Duration and focus on Cost of Delay only, or some other set of parameters.
It’s the Numerator that matters far more
Having said all that, I’d strongly recommend you don’t get bogged down in pointless navel-gazing about Duration and focus your energies more on the Cost of Delay part of the equation.
In the absence of information about Value, of course the system optimises for other things. Why should this surprise anyone?
— Joshua J. Arnold (@joshuajames) January 5, 2014