Prioritization in Lean-Agile
Focus on Cost of Delay rather than Business Value
Check out our training offer and the SAFe City workshop.
What is Cost of Delay ?
Cost of Delay is somewhat strange. The concept is pretty easy to grasp: what is the cost of a service or product not available now and of waiting for it. It is the cost incurred by a project delivering one month late. The Cost of Delay warrants the cost on-line web shops incur to deliver goods within 24 hours after ordering. Same day delivery gives a competitive advantage over shops delivering in a week, since customers do not like to wait and are prepared to pay for a shorter delivery time.
Experience shows that we do not use Cost of Delay in making conscious decisions in product development and project delivery. Don Reinertsen, in his book on Lean Product Development, notes that product managers make wildly different estimates of the Cost of Delay for their project, varying between 1 and 50. And he recommends focusing on Cost of Delay, as the single most important factor in prioritizing work and calculating the cost of waiting in cues.
Cost of delay in daily life
We do use Cost of Delay decisions in our daily lives and some examples will help grasp the concept better. Compare for instance a fire fighting truck with a garbage collection truck. One has a blue flashlight, a siren and has a status that allows it to break traffic rules as a ‘priority’ vehicle. The other has an orange flashlight.
The Cost of Delay explains the difference nicely. Firefighting has a very high Cost of Delay: every minute counts, as the rate at which the fire creates damage increases fast over time. Garbage collection has a low Cost of Delay: garbage can sit there for days and will only slowly start to cause damage. Is the firefighting more valuable than the garbage collection? Hard to tell; but when a fire occurs, it certainly is more urgent.
Comparing Cost of Delay to Business Value
Agile has always proposed that its mission is to maximize the generation of Business Value; per unit effort, per Sprint, in backlog prioritization. It seems hard to argue with: do the most valuable items first. But the firefighting – garbage collection example shows an issue with the reasoning. Priorities need to take urgency into account as well as business value.
The comparison of Business Value with Cost of Delay brings up an important point. Cost of Delay is, quite intuitively, expressed as monetary value over time, e.g. in € per month. Cost of Delay translates into Cost if we define the duration of the Delay. Mathematically: if we integrate the Cost of Delay function over a fixed period of time. In short, delays cause cost.
Business value is a vague term, but it is ultimately a financial value. So here is the difference: business value has no time dimension, Cost of Delay has. But business value is rarely a static point in time. Instead, something has business value because it generates value (money) over time, by generating profit or by decreasing cost. By focusing on the creation of business value alone we cannot really factor in the advantage of being faster. If we base priority on the business value generated per unit effort we can do worse, economically, than by focusing on items that generate business value faster over time.
However, it is hard to get our head around the ‘speed of value creation’, and it is easier to use the opposite concept: Cost of Delay. Optimizing value creation by minimizing the Cost of Delay looks slightly tricky, but it can really help to think more clearly on how to prioritize items and create a flow that generates more value for the same effort.
Priorities and Cost of Delay
We currently already prioritize items by Cost of Delay. Software bugs or hardware issues are prioritized by the severity of the consequences, not by the business value (arguably, there is none: the bug is a quality defect, so we have overestimated the value of what we already had). The urgency with which we try to solve the issue is clearly related to the Cost of Delay: the more people that cannot use the application and the more vital the functionality interrupted, the higher the Cost of Delay. It is often reflected as such in an SLA.
From the examples, we can see that we connect urgency to priority: a bug needs urgent fixing and has high priority, an ambulance or firefighting truck needs to arrive urgently and becomes a priority vehicle by flashing lights and using a siren.
We can use the Cost of Delay for prioritization in less dramatic circumstances, not just to avoid the cost of damage, but to faster create products that generate value themselves. Build the money saver fast, be first on the market and grab a large share before your competitor is ready, be first with a new technology and gain experience before everybody else: all of them can be prioritized using Cost of Delay.
Priority and Weighted Shortest Job First
Since Cost of Delay describes the cost incurred by not doing something over time, we also should consider the time needed to build the item. Fast realizing a functionality with moderate Cost of Delay can still beat the much slower realization of an item with higher Cost of Delay. We can estimate this effect by dividing the Cost of Delay by the duration of realization, so that a moderate Cost of Delay divided by a small duration results in a higher value than the higher Cost of Delay divided by the much longer duration.
Dividing Cost of Delay by duration (or by Job Size) results in the hard to pronounce ‘Weighted Shortest Job First’ parameter: WSJF, pronounced We Sjiff (in French pretty close to ‘Oui, Chef’…). The higher the WSJF, the higher the priority.
SAFe has a very useful and fast approach to estimating WSJF. This approach has in turn been captured by Mark Richards in the SAFe City Simulation game. ADJUGO has adopted this simulation and incorporated it into our standard Leading SAFe training. The game approach has in turn been adopted by a customer, who now uses it as a standard approach in management meetings for project (or feature) prioritization.
ADJUGO offers the SAFe City workshop also as a stand-alone solution to help teams and management with a fast approach to lean-agile prioritization.