Cost of delay and the elusive nature of value
In last week’s message, we looked at why development estimates should not be used for prioritisation - they are a poor proxy for overall cost.
Instead, we need a prioritisation approach that more closely reflects the importance of each piece of work to the business. We should be able to compare each proposed change - whether it aims to add value through new features, to improve existing features or to remove obstacles to value delivery.
That last category of change can be hard to make a case for because they are rarely compared on equal terms. We are focusing on the cost of doing the work, and not on the relief that completing the work will provide to the cost of subsequent work.
In the world of lean, estimating the cost of delay aims to provide a way to make better comparisons.
Let’s create a simple example of three new features for illustration. For each feature, we magically have good estimates for overall development time and for the value that having the feature available to users will add to the business. (Value is in Guatemalan Quetzals, of course).
| Feature | Dev time | Value to business |
|---|---|---|
| A | 2 weeks | Q5,000 |
| B | 6 weeks | Q10,000 |
| C | 1 week | Q4,000 |
Assuming these estimates are reasonable, what order should we deliver the features in? Which order of work will deliver value most efficiently? There are a few ways of prioritising:
- Work on them all in parallel and wait until they are all complete to release (assuming a team of at least three). This is the same as not prioritising at all.
- Value priority (most valuable first)
- Duration priority (shortest first)
- Both value and duration priority - i.e. the cost of delay divided by duration, divided by 1000, known as CD3.
Here are the same features with their CD3 values:
| Feature | Dev time | Value to business | CD3 |
|---|---|---|---|
| A | 2 weeks | Q5,000 | 2.5 |
| B | 6 weeks | Q10,000 | 1.7 |
| C | 1 week | Q2,000 | 2 |
| Total | 9 weeks | Q17,000 | - |
Now if we take each priorisation scheme in turn, we can work out the overall cost of delay.
1. Parallel development / big bang release:
It will be 9 weeks until any value is generated, and we lose Q17,000 every week in opportunity cost, meaning a total cost of delay of Q153,000.
2. Value priority
Here we work on each feature in order of value and release as soon as it’s done. The cost of each feature is the total weeks of delay - including queing time and development time - multiplied by the value.
| Feature | Dev time | Value to business | Cost |
|---|---|---|---|
| B | 6 weeks | Q10,000 | 6 * Q10k = Q60k |
| A | 2 weeks | Q5,000 | (2 + 6) * Q5k = Q40k |
| C | 1 week | Q2,000 | (1 + 2 + 6) * Q2k = Q18k |
| Total | 9 weeks | Q19,000 | Q118,000 |
3. Duration priority
| Feature | Dev time | Value to business | Cost |
|---|---|---|---|
| C | 1 week | Q2,000 | 1 * Q2k = Q2k |
| A | 2 weeks | Q5,000 | (2 + 1) * Q5k = Q15k |
| B | 6 weeks | Q10,000 | (6 + 2 + 1) * Q10k = Q90k |
| Total | 9 weeks | Q19,000 | Q107,000 |
4. CD3 priority
| Feature | Dev time | Value to business | CD3 | Cost |
|---|---|---|---|---|
| A | 2 weeks | Q5,000 | 2.5 | 2 * Q5k = Q10k |
| C | 1 week | Q2,000 | 2 | (1 + 2) * Q2k = Q6k |
| B | 6 weeks | Q10,000 | 1.7 | (6 + 1 + 2) * Q10k = Q90k |
| Total | 9 weeks | Q19,000 | - | Q106,000 |
Some conclusions:
- A big bang release is much more expensive than any incremental release order
- Working on the most valuable item first isn’t necessarily the most efficient approach
- In this case, prioritising by the cost of delay is not much better than prioritising by duration.
Results will vary enormously depending on what work you’re comparing.
Of course, in real life, things are not as simple as this example.
In particular, how do we arrive at the estimate of value for each piece of work?
What’s the value of work that keeps a key partner on board?
What’s the value of reducing churn by 0.5%?
What’s the value of rewriting the user authentication service?
What’s the value of introducing a design system?
It’s for this reason that it’s usually better to describe features as ‘bets’ or ‘guesses’. And technical work can be just as hard to value.
But I don’t think this means you shouldn’t try. Having value conversations and being transparent about its complexity is a key part of making appropriate prioritisation decisions that the whole team can get behind.
Value and cost of delay discussions keep the team focused on what’s important for the business and not just motivated to become the most efficient execution unit it can be, measured only by how hard they are shipping.
How might you start thinking more about value and the cost of delay in your work?
All the best,
– Jim
