Prioritization with cost of delay

Prioritizing is one of the most important and difficult activities in any Product Owner’s life. Most of the time the difficulty in prioritizing occurs because people have different opinions about the impacts that each Product Backlog item can have on the final product.

Well, and that’s the problem. Prioritization based on opinions (which usually have a weight proportional to the weight of the badge of whoever is opining). When we somehow manage to tangibilize the value of each item in our Product Backlog, the discussion becomes much more rational.

One way to better understand the value of each feature comes through a simple question: how much are we losing by not having delivered this item yet?

Answering this question is not always easy, and often involves a lot of research work. The important thing is to always remember that we’re not always looking for super precise information here. The purpose of understanding the value of each item is to help us make a rational decision.

For example: let’s say a certain item will earn me between $6,000 and $40,000. This range is very wide and may seem to have little value, but if I know that the cost of the item should not exceed $3,000, I can already make a decision and don’t need to invest more time refining my research to narrow this range.

Different types of cost of delay

Each item can have a cost of delay in a different format: some tend to grow linearly and others exponentially. There are also those with a fixed date, like compliance with a law with a date to come into effect, and others whose cost doesn’t have such a relevant relationship with delay time. Understanding which types of items you have in your Product Backlog is the first step to rationalizing your prioritization process.

The most common type of item found in a Product Backlog are those whose cost of delay tends to increase over time, whether linearly or exponentially. Imagine a product with the following items in its Product Backlog:

Table with Product Backlog items and their costs

Each item has an estimated cost per week of delay and an estimated development time. If we divide the cost of delay by the duration of each item, we arrive at the famous CD3: Cost of Delay Divided by Duration.

But why is this CD3 important? To answer this question, let’s try to prioritize this backlog in three different ways.

Prioritization by size

If we choose to deliver the smaller items first, our delivery curve would look something like this:

Prioritization by size graph

In the first week we would have a cost of delay equivalent to all items summed up (2,000 + 5,000 + 6,000 + 1,500), after all we haven’t delivered anything.

At the end of week 1 we managed to deliver the Notifications item (which was prioritized for having the shortest duration) and with that we reduced our total cost of delay by 2,000. And then we repeat this process for the next items in the Product Backlog.

At the end, we have the following scenario:

  • 1 week with total cost of delay of 14,500

  • 2 weeks with total cost of delay of 12,500

  • 3 weeks with total cost of delay of 11,000

  • 4 weeks with total cost of delay of 6,000

In this scenario our total cost of delay was:

(1 x 14,500) + (2 x 12,500) + (3 x 11,000) + (4 x 6,000) = 96,500

Prioritization by value

When we prioritize by value, things change a bit:

Prioritization by value graph

  • 4 weeks with total cost of delay of 14,500

  • 3 weeks with total cost of delay of 8,500

  • 1 week with total cost of delay of 3,500

  • 2 weeks with total cost of delay of 1,500

In this scenario we start working with the APP item because it has the highest cost of delay per week. At the end we have a total cost of delay of:

(4 x 14,500) + (3 x 8,500) + (1 x 3,500) + (2 x 1,500) = 90,000

Prioritization by CD3

Prioritization by value generated a slightly better result, but we still have room for improvement. See what happens when we prioritize by CD3:

Prioritization by CD3 graph

  • 1 week with total cost of delay of 14,500

  • 3 weeks with total cost of delay of 12,500

  • 4 weeks with total cost of delay of 7,500

  • 2 weeks with total cost of delay of 1,500

(1 x 14,500) + (3 x 12,500) + (4 x 7,500) + (2 x 1,500) = 85,000

A good reduction, isn’t it? And a great example of how a person acting as Product Owner can have a very positive impact on product development!

Conclusion

Knowing how to prioritize well is important, and to do so you’ll always need to have a good understanding of the value of each item in your Product Backlog.

Formulas like the CD3 calculation can help a lot once you’ve taken the first step: having this sense of value. But this first step is very dependent on the Product Owner’s proximity to the market and a good understanding of their customers’ problems. And well, there’s no magic formula for that. :)

Autonomy in the Retrospective
3 fake news you may have heard about Scrum