The cost of delay

The cost of delay - Dart board with dart in the bullseye with a priority tag

One mistake teams new to Agile development make is an overeagerness to always work on the highest value items. Once there are mechanisms to prioritize and make choices, there can be a knee-jerk reaction to always look quickly at the most value. It makes sense. This is how many enterprises work today on big business cases and capital investments.

Don Reinertsen, author of Product Development Flow, suggests that you have to take into consideration the ‘Cost of Delay’. That is the amount of value missed out on over time. Some things lose value very quickly, whilst others take a long time. Some things are valuable for a very long time, some are more transient. By considering the cost of delay you add urgency into your prioritization calculation, which helps you consider if you’re using your capacity in an optimal way.

Whilst people should make the ultimate call on what’s worked on, a quick rule of thumb is to use what we call CD3 (cost of delay divided by duration) to schedule work.


How quickly or slowly does the value/benefit of your priorities stack up against other items on the backlog? Are you making the best choice?