Agile focuses on value. This is good but when it comes to prioritising we could be more refined than prioritising greatest value. Instead we should be focusing on fastest value, which is slightly different.

The literature on cost of delay is where we find the explanation. It tells us to prioritise by something called “cost of delay divided by duration”, aka CD3. Here’s how it works…

Let’s suppose we’re working on a project and we have three features we can implement, but only one at a time, so we have to prioritise them. Each feature gives us a number of units of value, but takes a while to implement. It doesn’t matter what our units of value and units of time are, but for this example let’s say our unit of value is £10,000 per week, and our unit of time is 1 week. So we’ll suppose Feature A generates £40,000 per week (4 units of value), but takes 2 weeks to implement; Feature B generates £50,000 per week but takes 3 weeks to deliver; and Feature C generates £60,000 but takes 5 weeks to deliver:

I don’t think it’s obvious which sequence we should best implement these in, so let’s go for greatest value first. If we do that we get something like this:

This shows us that we start work on Feature C, and we get no value until week 5 when it’s delivered and we generate £60,000 per week (6 units of value). We keep generating that every week, and meanwhile immediately start work on Feature B. That takes 3 weeks, and at the end of it we start generating £50,000 per week. That’s on top of our £60,000 per week from Feature C. And as soon as B is delivered we start work on Feature A which takes 2 weeks, after which we’re generating a further £40,000 per week. At the end of 10 weeks we’re delivering a steady £15,000 per week. The chart shows this continuing, and for convenience we stop the chart at week 14.

Adding up all the space in the rectangles we can see that after 14 weeks we’ve generated £160,000.

Pretty good, but could we do better? Here’s a different sequence. This time we’ll reverse the order—yes, least valuable first. It looks like this:

This time we get less value from our first delivery, but it is delivered quicker. After delivering all the features we’re still generating the same £15,000 per week (because the value of the features still total the same) and we get to this point in the same time (10 weeks, because the total time to deliver the features is the same). But are we better or worse off overall?

I don’t think it’s obvious just by judging by eye, but if we do the maths we find that after 14 weeks we’ve generated £117,000 of value. That’s an £11,000 gain from our original sequence.

What made this a better sequence? Or to put it another way: If we had fifty features to prioritise instead of three how would we know which is the optimal sequence? Because doing this kind of maths on each possible sequence would be awful.

We can work towards our answer by adding some lines to our first sequence, like this:

The blue lines simply show how quickly it took to get from starting to implement a feature to actually getting its value. It’s the speed at which we got to the value.

Here’s the same thing with our second sequence. This time we use red lines:

Finally, let’s overlay the two diagrams:

Remember that the second sequence—the one with the red lines—gave us the greatest benefit. And we can see from this diagram that this optimal sequence is the one that priortised the features with the steepest lines. The lines from our original sequence start out much shallower.

What is this measure of steepness? It is how quickly we get to the value. Or more technically it is the gradient of the line: the value of the feature divided by the time it takes to deliver it. The steeper (greater) the gradient, the higher we should prioritise it.

In the jargon, the value of the feature per time period is called “cost of delay” because for each unit of time that passes before we deliver that is how much we lose by not having it. The time it takes to deliver the feature is the duration. That’s how we get to “cost of delay divided by duration”. Or in simpler terms, how quickly we get to the value.

The cost of delay literature can be hard work, and to be fair it covers more cases than what we’re expressing here. But one essential message is this: prioritise by fastest value.