Cost of delay: how to calculate quantitative cost of delay and CD3

In my last post, I introduced you to qualitative cost of delay and CD3. I argued that rational teams should order their backlog for maximum economic benefit and that you can use cost of delay divided by duration (CD3) to do that. Because software developers aren't accountants, I used the easier to understand qualitative cost of delay and CD3 in my examples. But in this post I'm going to discuss at the advantages of switching to quantitative cost of delay.

I know this stuff isn't as interesting as reading about the latest advances in AI or your favorite framework. But trust me when I say that learning to order your backlog by quantitative CD3 will help you take your effectiveness to the next level.

Why calculate quantitative cost of delay?

Qualitative cost of delay just gives us a unit-less score. It's a crude measure of the urgency and value of a story. When you divide it by duration, you can use it to roughly order your backlog but that's about it. Quantitative CD3 is more accurate than qualitative CD3 for ordering the stories in your backlog, which is a huge benefit. But that's just the beginning of what you can do with quantitative cost of delay.

Make better tradeoffs using quantitative cost of delay

You can use quantitative cost of delay to make rational decisions about the hundreds of little and big tradeoff decisions your team makes every day.

For example, is it better to:

• release a new version of your software today or spend another month fixing bugs?
• hire another software developer or work with the people you have?
• refactor a messy module now or leave it for another time?
• update the slightly misleading variable name so the code is a little easier to read for the next guy or leave it?
• keep your people busy or reduce their utilization and focus on reducing cycle time?

You can use quantitative cost of delay to help you answer these kinds of questions and more. I plan to show you how to do that in a future post.

Speak the language of business

Money is the language of business. If you want to get your ideas and changes implemented, show the decision makers in your company the economic benefits of your ideas.

Want to tackle some technical debt? Show them how much it's costing your company not to tackle it. Want buy some software make something go faster? Show them the numbers. Want to spend some time improving your security? Show them the impact.

How to calculate quantitative cost of delay

Okay, so how do you actually calculate quantitative cost of delay? The short answer is that you calculate the marginal impact on after-tax lifecycle profits of your potential actions.

Don't panic. I promise that it isn't as bad as it sounds. I'm going to break this into small steps for you. First, I'm going to present you with some general advice. And then I'll show you some examples.

Partner with an expert in your company to help you calculate the cost to delay

You will likely want a partner to help you figure this stuff out. This might be the product owner, somebody from accounting, or somebody with specialized knowledge of the economics of your projects. Business people are used to thinking in dollars and cents and you shouldn't have too much trouble getting them to help you once you explain what you are trying to do.

Use an appropriate level of effort and rigor

You need a different level of rigor in your cost of delay calculations for developing all the software for a new fighter jet as compared to adding a newsletter sign up form to your company blog.

Use common sense and stop when you have answers that are good enough. For example, if the top three stories in your backlog have CD3s that are orders of magnitude larger than the other stories further down in your backlog, you probably don't need to analyze those other stories now.

In most scenarios, the marginal impact on after-tax lifecycle profits of a story are going to be overwhelmingly driven by only a few factors. This means you can use simple models to get answers that are good enough.

Tip: you can use the Theory of Constraints to guide you to potentially valuable stories, which are usually related to your system constraint.

Use a spreadsheet

If you build your cost of delay models in a spreadsheet and make your assumptions explicit, you'll find it easier to update and change your assumptions as new information becomes available (see the example below).

The importance of marginal economics

You only want to consider costs and profit that will change with your decision. Lots of people, even business people, make mistakes here. The biggest mistake people make is when they consider "sunk" costs. Sunk costs are costs that you've already incurred (or that you haven't yet incurred but you can't avoid).

Let's look at a quick example. If you've worked on a feature for five weeks and you're got two more weeks to go, those first five weeks are a sunk cost. This has an interesting effect on your CD3 over time. If you assume a fixed cost of delay of say $5,000 per week, you might start with a CD3 of $5,000/7 weeks = 714. Five weeks into the projects, you only have two weeks remaining so the math looks like this: $5,000/2 weeks = 2,500. As the duration remaining decreases, your CD3 score will approach infinity.

This makes sense when you think about it. Would you ever shelf a feature that will make $5,000/week in after tax profit that you could finish in one hour? I wouldn't (unless another story had a higher CD3). Let's work out the CD3. One hour out of 40 hours in a work week = 0.025. So, $5,000/.025 = 200,000. That is a very different answer than the CD3 of 714 you get when you calculate the non-marginal CD3.

Here is the same data displayed graphically (with CD3 rising as duration remaining decreases).

Lifecycle profit vs cashflow

Most of the time you should be interested in lifecycle profits when you are calculating quantitative cost of delay. However there are cases where cashflow is more important. Companies with extremely high growth rates or companies fighting for their survival may need to worry about cashflow more than lifecycle profits.

If you're in this situation, the smart move is to sacrifice some long term profitability to make sure you can meet your short term financial obligations (like making payroll and paying your suppliers). You'll likely know if you're in this situation but if you aren't sure any business type in your company will definitely know the answer. Adjust your cost of delay calculations to meet your company's goals as required.

An example of calculating quantitative cost of delay and CD3

Suppose you work for an e-commerce website and you are considering two new features and you want to determine which feature has the higher priority using quantitative CD3:

• Feature A: streamline your checkout pages to increase their conversion rate.
• Feature B: update your tax rate calculations so you can expand into a new market with a different tax rate.

I made a spreadsheet to calculate the cost of delay and CD3. It looks like this:

With the assumptions I used, feature A has a CD3 score of 300 and feature B has a CD3 score of 7,200. So if everyone agrees with those assumptions you should work on feature B first.

But, everyone might not agree. And if that's the case, you can easily tweak your assumptions (yellow cells) and see how they effect your outcome (purple cells). Software developers are already familiar with estimating duration. This is just a small extension of that idea.

You can take another approach too. You could ask how much the conversation rate on feature A would have to rise to make its CD3 score the same as feature B's CD3 score? Let's see what that looks like.

I punched in a few values for the "new conversion rate" and found that it would have to be 52% to have the same CD3 score as feature B. I've never heard of a 52% conversion rate for a long term e-commerce site. So, I'd say that it's a pretty safe bet that feature B is a higher priority than feature A.

Wrapping up

I know you might not be excited about spending your time calculating cost of delay and CD3. But your team will have a very difficult time being effective unless somebody's doing it and you'll find it also gets easier with a bit of practice. Our intuition for finding and working on the most valuable thing isn't good enough to wing it. You'll be shocked by what you find if you spend some time quantifying the cost of delay for your high priority backlog items.

In my next post in this series, I'll show you how to deal with stories where their urgency changes over time. Stay tuned.

Agree, disagree, comments or questions? I'd love to hear from you.

Additional resources

You might find the following cost of delay resources helpful:

• excellent website with a great three minute explainer video
• book: "The Principles of Product Development Flow: Second Generation Lean Product Development" (Donald Reinertsen) Chapter 2
• book: "Essential Scrum: A Practical Guide to the Most Popular Agile Process" (Kenneth S. Rubin) Chapter 16
• video of a talk by Donald Reinertsen on product development