It is often very difficult to prioritise what to build and when. One of the most efficient methods of prioritising features is prioritising according to cost of delay.

Originally invented by Don Reinertsen in “Managing the Design Factory” as a new way of looking at how to build stuff, it has inspired many agile teams to apply this thinking in their sprint planning efforts.

The problem is always how exactly to find out what the cost of delay is. It is notoriously difficult to put a price tag on a feature. This is probably what has discouraged most people from doing it. But the fact that you can’t put a precise price tag on the cost of delaying a feature shouldn’t keep you from applying this kind of thinking.

One very good solution to how you might do this is provided by Dean Leffingwell in his book: “Agile Software Requirements”. He argues that cost of delay can be broken down into three components: User value, Time value and Risk reduction.

How To Break Down Cost of Delay

User value is the potential value of the feature in the eyes of the user. Product managers or product owners usually have a good feeling for this, but other parts of the company like consultants or sales people who spend a lot of time will also have a pretty good understanding this as well. One should not forget that asking the user him or herself is the most obvious solution. The reason why most people don’t so this is probably that it is relatively cumbersome at scale. At Sensor Six however we have seen customers use our product with great success to engage directly with customers to get input on the user value. Often a company will have a customer panel or a mailing list, where it is natural to ask your customers. It doesn’t have to be real value, but something simple as a 10 point scale could easily be used. More sophisticated uses we have seen with our customers is the use of forced ranking, which is an excellent way of measuring if you don’t have too many features to rank.

Time value is based on how user value decays over time. Many features are more valuable if they are delivered to the marketplace early, so they can provide differentiation. This depends very much on an analysis of competitors current state and what is assumed they are working on. This is why it is usually business analysts or product managers who will be able to rate this. Again it is possible to just use a 10 point scale to measure it.

Risk reduction/opportunity enablement describes the degree to which a feature helps us mitigate risks or exploit new opportunities. We live in a world with many unknowns and therfore it is important to be able to guard yourself against the unknowns that are threatening (risks), but also to remain open to the ones that could help us (opportunities). This evaluation will always be very subjective and dependent on the person doing the rating. Since people have very different perceptions of risk it is a good thing to invite several people to ascertain risks.

I would say that these are really good suggestions, but there could be other approaches as well. Leffingwell argues for rating thes on a scale from 1 to 10, but that can also depend on the context. If you have very few features and want a very precise measurement you should use a relative method such as ranking or pairwise comparisons. But in the end it is more important to have some sort of indication, so an easy method like a 10 point scale will be a good place to start.

How to Use the Cost of Delay Calculation For Prioritisation

The cost of delay of a feature is the same as the value it has if it is not delayed, ie. produced. Now that you have this value the next thing you would want to do is hold it up against the effort it would take to produce the feature. Effort can be estimated in the same way with a 10 point scale. If you work in an agile context you may as well use story point if that is possible. Here is where you can get your engineers to look at the features and give some sort of estimate.

Once you have som data on the effort there are several ways you could attack the problem. According to Reinertsen in The Principles of Product Development Flow there are two ways:

Shortest job first is the method to use if you want to look at minimising effort. You simply start with the features that are smallest and work your way through them regardless of the cost of delay. If features all have the same cost of delay, this is the best way to do it.

High Delay cost first is where you simply start with the features that have the highest cost of delay regardless of the effort. This is efficient in producing a high economic output. If features have the same effort this is the best way to do it.

Weighted shortest job first is where you weigh the value against the effort. If features have different effort and value, which is most often the case, this is the most efficient method to use.

How To Do It In Practise

Strangely, given the popularity of this thinking, no tools seem to support this particular way of prioritising, so it is always something that needs to be done in spreadsheets. To our knowledge Sensor Six is the only product management tool that does all of the above out of the box and even makes it possible to engage different stakeholders directly. In the following I will show how you can do exactly what Leffingwell recommends in Sensor Six.

You can see how the above would be set up in Sensor Six by going to our website and logging in with the credentials below or you can follow the step by step guide to prioritise your own features.

https://sensorsix.com/login
 CODdemo
7uJI%1JK

Doing Cost of Delay Prioritisation In Sensor Six

First you set up the different criteria: User Value, Time and Risk Reduction. You configure them as benefits and a 10 point scale. Supply them with a description.

Now you can rate them solo and evaluate everything by yourself. If this is fine and sufficient for your needs you may skip the next section.

If you want the product manager, sales rep or any other stakeholder group who are fit to act as a proxy for the user to evaluate user value simply go to the collaborate section. Here you can configure a workspace that will allow the user to give input to the user value. Simply copy the link to the workspace and send it to a list of people who you think could give you this input. Have the competitive intelligence function whether it is located in marketing or some other division rate the time value to get input on the time cost of delay per feature. Let the business analyst give input on the risk reduction opportunity dimension. Finally you need to know something about the effort. This you will invite your engineering department to work on.

The actual persons or roles can be cut differently, so maybe you will ask the same persons to rate the time and risk reduction domains (typically business analysts), engineering will estimate the effort while sales or support may evaluate user value.

When you have input on the cost of delay, you can plot the total cot of delay on the y axis and the effort on the x axis.  You should then choose those with the best cost of delay/effort tradeoffs first in order to arrive at the most efficient development plan, if your features have varying effort and cost of delay.

So this simple process can save you hundreds of hours and deliver more value to the market place quicker.