Cost of Delay - The Economics of Development Priorities
One of the hardest parts of managing the development pipeline is to make the economic reality of the planning trade-offs explicit.
The basic question is: Given N features in the backlog what is the best order to build them?
Most agile methods assume that the Product Owner will pick the best sequence. However, the Product Owner often does not do this, or at least, they often do it without making the economic trade-offs explicit. While they may have written a business case for the whole project before starting, it often fades into the background as the project progresses, when the detailed planning decisions are made week after week.
Sometimes ideas from lean, Goldratt's Theory of Constraints or the kanban idea of controlling the queue length are used to sequence the work. Or it could be decided by individual sentiment, where the more interesting job gets more attention or a task is expedited by someone offering chocolates or other bribes...
In his excellent book "The Principles of Product Development Flow", Don Reinertsen proposes to manage the business case throughout the project by making the economic impact of the planning choices explicit.
One of the tools for this is the concept of Cost of Delay.
Let's have a look at an example.
A Tale of Two Sites
Assume that we have two web sites, a small one focusing on vintage motorcycles, and its bigger brother, focusing on cars. Now, we want to introduce paid subscriptions to each of these sites.
The cars site has more users, so we assume that it will bring in 100,000 in sales for subscriptions on a weekly basis. For the MC site, we expect only 10,000 per week.
Now, it so happens that the car site is old and building a subscription module for it would require 8 weeks of development effort, while the MC site would only need one week.
Which feature should we develop first?
The total cost is the same (8+1 weeks). However, the revenue streams look different.
Assume that we decide to do the MC site feature first, then develop the Car site. Then, the sales look like this for the first ten weeks (development is 1 + 8 weeks in total).
If you were only worrying about queue length, that is what you would do. We would build the smallest feature first to minimize the average queue time.
Let's look at the other alternative, building the 8-week cars feature first, and then the MC feature after that.
Now the cash flow looks different.
The cost of delay of the cars feature is 100,000 in sales per week, while it is only 10,000 for the MC site.
Hence, if we schedule the MC feature first, we get it after one week, and the Cars feature after 9 weeks. However, we pay the price of delaying the sales on the car feature by one week, and that costs us 100,000, while we only earn 8 weeks extra on the MC feature, or just 80,000. The net difference is 20,000.
In this case it yields a better economic outcome to build the big feature first even if it blocks the critical development resource for a long time.
The trick is to look at the cost of delay weighted by the development time. Then we see the MC feature at 10,000/1 week vs 100,000/8 weeks for the cars, or 10,000 to 12,500. By this, the car feature wins the priority (ceteris paribus).
What Don Reinertsen proposes is simply to make this kind of work integral parts of the planning process. If the trade-offs are explicit and well known to everybody, independent decision making in the team will be based on better information and better economic outcomes can be achieved.
I highly recommend his book for everyone in product development, including, of course, anyone leading a startup.
Note: Edited July 3rd, 2014: changed illustrations from TIFF to PNG images so they will show up on more browsers.