Unquantified cost of delay in prioritization

Cost of delay (CoD) is an old financial tool for evaluating the cost that is assumed to happen when something is delayed. Its importance in (software) development work probably increased remarkably after Donald G. Reinertsen published The Principles of Product Development Flow (at least from my point of view). In his book Reinertsen explains very thoroughly why CoD is a really important metrics and why it can be a valuable tool to be used in prioritization. His principle E3 says:

The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay (p. 31).

What comes to the prioritization, Reinertsen offers for example this simple advice related to CoD:

I'll just give you two simple heuristics: high cost of delay before low cost of delay, and short jobs before long jobs (p. 70).

So basically it's quite a simple thing. Just calculate the CoD like Reinertsen does and decide. But is it really that simple in practice?

Cost of delay without numbers?

As a development team member I'm making many prioritization decisions every week. Obviously I try to make good decisions together with other team members and stakeholders. In theory CoD is almost all I need but in practice there's a big challenge how to quantify it. Either the numbers aren't available or it is not cost effective to get them. I suppose that Antti is facing the same problem and for that reason doesn't know how to utilize CoD in his work.

Fortunately it is still possible to use CoD in prioritization even though we wouldn't have numbers available. The key is to understand the different types of CoDs.

Example

This is quite a recent example and related to the original tweet. We had to decide whether to implement feature A or feature B first.

The company was about to start a print marketing campaign. The question was: should they include the feature A to the marketing material or not? Obviously if they mention about it, the feature has to be ready when the campaign is out. If they do not mention it, there's no hurry with building the feature but then they miss an opportunity to sell the feature for the potential customers during the campaign.

The feature B on the other hand was more of a "regular" feature. There was no marketing campaign related to it, nor any seasonal specialties.

Without having any numbers available, I was immediately thinking how the CoD curves would look like in each case:

 

Cost of Delay - Feature A

 

Cost of Delay - Feature B

The feature A has a cost of delay that is clearly related to the marketing campaign. The cost here is the lost additional sales that the campaign would probably bring to the company. The feature B has no such attribute. The lost sales (or satisfaction of the current customers or some other value) increases steadily among the time. Based on this we decided to prioritize so that we build feature A before B so that the company would not lose the opportunity window that would be open during the campaign.

Is shape enough, don't absolute numbers matter?

There is a reasonable question flying in the air. Are you sure that the curve for the feature A is above the other curve? In other words, how can you be sure that when combined, the curves don't look like this?

 

Possible cost of delays

My answer is that we cannot know for sure. But we have some hints that we can look at. The implementation of both features has been delayed already for quite a long time. If the CoD curve of the feature B would be very steep, the feature would have been probably implemented a long time ago. We can reasonably assume that since both features have been approximately at the same height in the backlog, their business value is pretty much the same. Now it just happens to be so that feature A fits very well for the marketing campaign that is about to be started. And the campaign starts no matter whether this particular feature is ready or not.

Classes of services

Another person who has popularized CoD in software development is David J. Anderson with his Kanban: Successful Evolutionary Change for Your Technology Business book. (Btw, check who has written the foreword for the book.) Anderson talks about classes of services - expedite, fixed date, standard, and intangible - and relates them to the different kind of CoD curves.

I'm not going to talk about more of them in this post, you could read e.g. Andy Carmichael's excellent blog post Selecting Backlog Items By Cost of Delay. Another post worth to mention is Mike Burrows' Kanban prioritisation and scheduling with classes of service. Nevertheless, I think that understanding those classes helps you in using CoD in your daily work, even without quantifying the cost.

Summary

I would like to emphasize that I'm not trying to understate the importance of quantifying CoD. And I really like how Reinertsen highlights that our decisions should be based on quantifiable economics instead of e.g. gut feelings. However, in real life the available data is very often insufficient and getting better data isn't necessarily cost effective. Still you need to make decisions and you try to do them as well as possible. In those cases it helps if you understand the principles of CoD, even when you decide not to quantify it.

Another point of view is that in agile software development we try to make many small decisions over the time instead of few big ones in the beginning. Then it doesn't matter so much if the decisions made are wrong because we can usually fix them rather quickly. In that kind of world using too much time on getting exact information isn't necessarily justified.

Obviously the bigger the impact of the decision is going to be, the more you should invest in making better analysis of the situation and actually quantify the CoD. And you can always think how you could improve your system so that relevant data could be available for the smaller decisions as well.