Posted on

A Practical Guide To Doing Cost Of Delay Based Prioritisation

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.

 

 

 

 

Posted on

Product Idea Triage

When I was training to become a fire fighter in my younger days, we also had training in wartime disaster relief. This is where you learn how to set up emergency hospitals in tents and rescue injured people from collapsed and collapsing buildings while everything is on fire around you in the middle of a firestorm. Good stuff to know.
But one of the more relevant and well known techniques we learned, once you actually locate and rescue someone is triage. In general triage is a way of sorting people into groups of priority, that is, who needs most immediate medical attention. There are several different schemes practiced around the world, but we learned to use three different groups:
A) Those that were not critically injured and who needed medical attention at some point, but could wait
B) Those that were seriously injured, but were able to survive if they were given immediate medical attention
C) Those that were mortally wounded and who, given the circumstances, would not be able to be saved
This is a tough decision to make, but we were training for wartime or serious catastrophes (I have actually tried triage myself at an American hospital. That was a very pleasant experience, because I got put into the B category apparently and skipped the long line in the emergency room. My serious, though not yet mortal wound, was being bit in the nose by a dog. Yes I know, I should have known better since I have also trained sheep dogs, but I feel we are drifting a bit off topic here…

Idea triage
I often encounter the gordian knot of prioritisation in software companies: it is impossible to find out which ideas to build first. That leads to prioritisation paralysis. There are too many ideas to work on and you don’t know for sure which ones will be of most value. You need to specify in more detail the idea before you can ask your engineers to build it. It may be necessary to do a mock up or describe some business rules. It could be that it is necessary to do graphical design. You can immediately see that some ideas are more well shaped and don’t need so much work, while others are just too complicated. Some ideas are urgent and need to be built immediately. They could be bugs, while others can easily wait. How do you get started? You probably don’t just start from idea number one.
In this case you can use the same triage technique as I mentioned above. You just have to tweak the meaning of the triage categories a bit:

A) ideas that have some potential but are in no particular rush to be made. They may need a bit of polishing and precision, but there is no need for immediate action. Ideas in category “A” can just be queued for when you have a moment to work on them. They could be customer requests, infrastructure features, annoying but non critical bugs etc. These should be treated as buffer tasks that can be picked by engineers when they are idle.

B) Ideas that have some potential, need to be made immediately. Ideas in category “B” are critical bugs, responses to competitors, or any other thing that has a large time to market constraint. They should be put into the most immediate sprints or releases. If needed other ideas should be taken out of the Work In Progress and parked.

C) Ideas that have very limited potential of immediately becoming fruitful. Category “C” ideas are those that are typically too complex to build quickly. It will take a long time to conceive, design and build them. However there may lie a huge potential here. The trick is therefore to selectively choose some that have a huge potential benefit. They could be big bets or the like. Find a percentage of work effort that can be dedicated to following unlikely successes, so you don´t miss out on great opportunities.


The process
Ideally every idea should be scored according to the strategic parameters of the company, but I realise that this is often not feasible. Either because it is too cumbersome or because there are simply too many ideas. This is why we suggest this faster, but more crude feature triage. The product manager can either do it himself or together with the engineering team. It is a good idea to have both market knowledge and technical knowledge present since you will have to gauge the feasibility and market urgency of the idea.
One way is to get three signs (for example blue, white and cyan. For each idea, each participant holds up the triage sign he or she thinks it belongs to. In case all signs are the same color this feature is simply given this triage category. In case of disagreements the reasons for this disagreement should be discussed. If after 5 minutes the disagreement has not been settled you go to a vote. It is important to have an unequal number of participants. If this is not possible and the votes are equally distributed the triage is decided with a coinflip.
This way you will quickly have escaped prioritisation paralysis and be ready to do some actual and sensible work.