The Cost of Delay in Prioritizing the Product Backlog

I ran across a really interesting article this morning from Derek Huether on the Leading Agile blog that introduces a concept called Cost of Delay for making decisions about how to prioritize the product backlog. By way of quick explanation, Huether writes, “I tell customers that if they want to save or make the most money, they need to prioritize their backlog… by money.”

“Don’t just ask what is the most valuable,” Huether says about prioritizing development work, because more often than not, when customers are pressed about which features hold the highest priority for them, they’ll respond by saying that all features are of equal importance. Instead, Huether advises, “Ask the question, ‘what will cost us the most, by delaying its delivery?’” The reason for thinking about the product backlog this way, Huether writes, is that “We’re not profiting from a feature that is not in production, so therefore, we are losing money every day it’s not out there.”

The concept of Cost of Delay is closely related to a concept in finance called the Cash Conversion Cycle. For an organization that produces something, whether that’s software or automobiles, the company invests in raw materials that progress through a series of processes where value is added at each step, culminating in the final product. The time that it takes for those raw materials to become something the company can gain revenue from is called the cash conversion cycle, and is an indicator of the company’s efficiency in operations. As I wrote about in a white paper called The Business Case for DevOps, in software those raw materials consist of the company’s investments in IT salaries and infrastructure, which is applied towards delivering valuable products and services. The longer the amount of time it takes to release a product or new functionality, the greater the amount of the company’s capital that is tied up, unable to produce revenue or be applied to other investments.

Huether’s concept of Cost of Delay applies this logic towards prioritizing the backlog in such a way as to shake free the revenue potential of those new features as soon as possible. To illustrate, he provides an example that compares three feature candidates for prioritization, and walks us through the Cost of Delay results for each possible scenario.

In prioritizing these features in the backlog, there are four potential scenarios. First, apply no priority to the features at all, and work on all of them at the same time. Second, prioritize the features by the duration of work – shortest duration first. Third, prioritize features by which are most valuable. The final scenario is to prioritize features by which have the highest CD3 (feature value divided by the duration).

The total value of these three features to the company is $19,000, but according to Huether, when that revenue is realized is an important factor for the business. “For every week features are not making us money, they are costing us money,” he writes.

In the first scenario, all features receive the same priority and are worked on at the same time. In this case, the $19,000 won’t be realized until all three features are completed. Since development duration adds up to 13 weeks, that means the $19,000 won’t be realized until week 14. But during all of that development time, the company is losing money on those features which are still works in progress. As Huether puts it, “For the 13 weeks we are working, we incur the Cost of Delay of all three features: $3000 + $7000 + $9000 per week.” Therefore, total Cost of Delay in this scenario is $247,000.

In the second scenario features are prioritized by shortest duration first. This means that in week 4 the $3,000 from Feature 1 will be realized, in week 8 the $7,000 from Feature 2 will be realized, and in week 14 we’ll realize the value of Feature 3, $9,000. In calculating Cost of Delay, we incur the full delay cost during the first three weeks of development until Feature 1 is completed – $19,000 x 3 – or $57,000. During the following four weeks while work on Feature 2 is being done, the delay cost only applies to features 1 and 2, or $16,000 per week, for an additional Cost of Delay of $64,000, bringing us to a total of $121,000. During the final six weeks of development, delay cost is only incurred for Feature 3, or $9,000 per week, adding up to $54,000 and bringing the total Cost of Delay to $175,000.

In the third scenario, we prioritize features by which are most valuable, meaning that we’d first work on Feature 3 (value $9,000), then Feature 2 (value $7,000), and then Feature 1 (value $3,000). Since Feature 3 takes six weeks to develop, we’d incur the delay cost for all features of $19,000 per week for those six weeks, which adds up to $114,000. During development of Feature 2 we’d incur an additional delay cost of $10,000 over four weeks, or $40,000. Finally, Feature 1 will incur a delay cost of $3,000 per week for three weeks, or $9,000. The total Cost of Delay in this scenario would be $163,000.

In the last scenario, we’ll divide each feature’s value by the duration of development (CD3) and prioritize by the largest CD3. From the chart above, that would give us a prioritization of building Feature 2, then Feature 3, and finally Feature 1. For the four weeks we work on Feature 2, we’ll incur a delay cost of $19,000 per week, or $76,000. Next we work on Feature 3 for six weeks, where the delay cost will be $9,000 + $3,000, or $12,000 per week, which over six weeks adds up to $72,000. Last is Feature 1, which incurs a total delay cost of $9,000 over the three weeks Feature 1 takes to develop. In this final scenario, the total Cost of Delay adds up to $157,000.

So in this fairly simplistic example, we see the total Cost of Delay for each possible scenario as:

1. No priority – $247,000
2. Shortest first – $175,000
3. Most valuable first – $163,000
4. CD3 – $157,000

While intuitively it probably makes the most sense to prioritize that which is most valuable first, this example shows that that is not necessarily the best economic decision to make when prioritizing the product backlog. Huether demonstrates to us the value in weighing the Cost of Delay when making these kinds of decisions.