Writing by Peter Hilton

Talking about the cost of delay

Another way to look at business value 2014-08-15 #agile

In an earlier article about development cost versus value, I suggested that there’s not much point getting upset about the quality of software development estimates for individual features if you have no idea what the business value is. After all, if you don’t know the value of a user story, knowing that it will take exactly two man-days to implement isn’t enough information to be able to decide whether to start work on it.

This is a real problem on Scrum projects, partly because the Product Owner has a hard enough job as it is, without the development team complaining that the product backlog is not properly prioritised and that that’s a problem. Which it is. Fortunately, there is an alternative to asking what a feature’s business value is.

Talk about cost of delay instead of business value

This week I met Joshua J. Arnold, who suggested talking about the cost of delay instead of business value. Simply put, cost of delay is the penalty for implementing something later instead of now. If cost of delay is a useful proxy for business value, then instead of asking the product owner to estimate business value, you can ask ‘what is the cost of waiting a week before we implement this?’

The benefit of talking about cost of delay, instead of business value, is that the conversation about the (development) costs and (business) benefits of prioritising work is now a conversation about two costs. This might turn out to be more comfortable and easier to quantify the stubbornly elusive business value.

Understanding cost of delay

There’s more to it than just a conversation about business value. Joshua’s web site has more explanation about Cost of Delay that explains the idea in far more detail, and offers three benefits, of which better prioritisation is only one:

  1. better decision-making
  2. better prioritisation
  3. changing the focus from efficiency and cost to speed and value.

If you are working on a software development project that has lost track of its business case, then these ideas might be just what you need to restart the discussion.

Photo: Lee Jordan

Share on TwitterShare on LinkedIn