I have previously shared my view on the way SAFe teaches Cost of Delay. It’s possible that the feedback came in too large a batch, so maybe I can break it down and suggest some incremental improvements. I’ll start with the part I struggle with the most and see if we can make it just a little bit better…
The SAFe “Cost of Delay” formula today
Here is SAFe’s formula for Cost of Delay, as it is today on the website:
Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement
One of my main challenges with this definition is that it adds ‘Time Criticality” to the other two parameters. To see why this doesn’t make sense, consider an option for which the “User-Business Value” = 0 and “Risk Reduction and/or Opportunity Enablement” = 0 but for which “Time Criticality” = 21.
In this case, SAFe is suggesting that
Cost of Delay = 0 + 0 + 21 = 21
This result clearly shows that there is a problem with the formula. If an option has zero value, then it shouldn’t matter how time critical it is, the Cost of Delay should be zero.
It has since been explained to me that SAFe practitioners do indeed recognise this as a problem. To cater for this, there is some sort of “strategy filter” which weeds out these sort of nonsense results. In effect, they put a lower bound of 1 on each of the components.
The need for this filter highlights that the SAFe formula poorly reflects the underlying principles of Cost of Delay. The filter doesn’t fix the problem though, it merely hides the most obviously flawed results.
What follows is a proposal for making a small, simple and hopefully as painless an improvement as I can think of. Assuming we can only use the same three qualitative inputs, how might we improve this?
The current SAFe formula has two terms which are both about Value (“User-Business Value”, and “Risk Reduction/Opportunity Enablement”. Depending on the sub-type, these map perfectly well to the four buckets of value that I normally use, which (when they are all denominated in the same scale or currency) we can combine into total Value like this:
Value = Increase Revenue + Protect Revenue + Reduce Cost + Avoid Cost
In the same way, we can continue to add UBV and RROE together, like so:
Value = User or Business Value + Risk Reduction and/or Opportunity Enablement
Quick sanity check: either one of these can be zero, but if both are zero, then value (and subsequently, Cost of Delay) should also be zero. So far, so good – and no change yet, so this should be easy to swallow.
Combining with Urgency
The main issue lies in how we treat the parameter that SAFe calls “Time Criticality”. I usually call this “Urgency” and ask people to consider which of the four most common Urgency Profiles that a value proposition can have. This helps them do a better job of estimating what the impact of time is on the outcome you’re interested in. The result is Cost of Delay, for which the units are $/week or £/month.
As we’ve already said though, we cannot simply add “Time Criticality” to the other two value terms. Urgency is orthogonal to Value. I’ve also tried to make the case previously that urgency alone is not enough, you need both. Urgency is the part that turns a feature for which the value is estimated to be worth, say, $2m into a feature for which the Cost of Delay is $10,000/week. The same feature with a different urgency could have a Cost of Delay of $20,000/week, or as low as $0/week. For those allergic to numbers, I already proposed a simplified qualitative Urgency. In this simplified model I proposed that Urgency is, in effect, multiplied by Value to get Cost of Delay.
Cost of Delay = Value x Urgency
Applying the same underlying principles to the SAFe formula give us:
Cost of Delay = (User or Business Value + Risk Reduction and/or Opportunity Enablement) x (Time Criticality)
If you have read this post about Qualitative Cost of Delay you should be able to see how these two align. In this case, you’re adding together two terms (U-BV and RR/OE) as Value on the vertical axis, with “Time Criticality” in place of Urgency on the horizontal axis.
This approach also means that practitioners who aren’t yet ready to try quantifying Cost of Delay can use a simple matrix for visualising Value x Urgency as above. Feel free to use SAFe terminology, or whatever words resonate and make sense in your context. It’s the meaning that matters.
Making this simple change would immediately put SAFe in a better position than the more common Value over Effort approach to prioritisation, which fails to account for urgency.
The aim was to improve the approach using the same three qualitative parameters. If those constraints were relaxed, we could go further. Of course, there will always be a continuum in the way people approach and start using Cost of Delay. (I am an Engineer, not a “purist”, and I am far more interested in the successful application of sound theory than religious adherence to an impractical theory.)
At least the underlying principles are now better reflected in the building blocks.