I first wrote about this on my old blog in 2012. 12 years later, they no longer recommend WSJF for story-level prioritisation but the other problems remain.
Weighted Shortest Job First (WSJF) is originally from Don Reinertsen’s The Principles of Product Development Flow.
WSJF = Cost of Delay (CoD) / Duration.
SAFe redefines WSJF as the following:
WSJF = (User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement) / Job Size (relative).
The good parts that SAFe has kept:
- Consideration of duration when scheduling work
- Consideration of cost of delay when looking at value
And now for the problems…
The purpose of quantifying Cost of Delay is to create a decision rule to support trade-off decisions between “improvements” and cycle time.
“We simply have no business trading money for cycle time if we do not know the economic value of cycle time.”
Don Reinertsen
For example, let’s say you are thinking of adding a new feature to the scope of the project which is estimated to be worth an additional $100k but will delay release by 1 month. If you already know that the cost of delay was $200k / month, the decision is pretty straight forward.
Reinertsen suggests that team member intuition of cost of delay will typically vary by 50 to 1 so having an explicit agreed value (e.g., $200k / month) has a significant impact on how decisions are made.
In SAFe-style WSJF, “cost of delay” is the sum of a set of relative size estimates. As an example, if User-Business Value was 1, Time Criticality was 3, and Risk Reduction and/or Opportunity Enablement was 5, the SAFe “cost of delay” is 9. Again, you are thinking of adding a new feature worth $100k but delays the project by 1 month. Your cost of delay is 9… Is the decision straight forward?
SAFe-style Cost of Delay is no longer useful as a decision rule for trade-off decisions.
Cost of Delay already accounts for overall value.
“The total profit of a high ROI project may be less sensitive to a schedule delay than that of a low ROI.”
Don Reinertsen
Project A provides $1M of value and its cost of delay is $100k / month. Project B provides $500k of value and its cost of delay is $250k / month. If we want to maximise life-cycle profits, the logical choice is to do Project B first and Project A after. That Project A is worth twice that of Project B is actually irrelevant.
The only thing we need to know is cost of delay.
In SAFe-style WSJF, “cost of delay” is the sum of three values:
- User-Business Value: relative value to the customer or business.
- Time Criticality: how user/business value decays over time.
- Risk Reduction and/or Opportunity Enablement: an aggregated proxy for eliminating risks early, value of information, and unlocking new business opportunities.
Project A provides $750k of user / business value, $250k of risk reduction / opportunity enablement value, and its cost of delay is $100k / month. Project B provides $250k of user / business value, $250k of risk reduction / opportunity enablement value, and its cost of delay is $250k / month. If we want to maximise life-cycle profits, the logical choice is to do Project B first and Project A after.
Just as before, the only thing we need to know is cost of delay.
So what is the point of adding User-Business Value and Risk Reduction and/or Opportunity Enablement to the equation?
SAFe-style WSJF misses the fundamental point that we do not need to know overall project value for prioritisation if we know cost of delay.
WSJF done with a relative scale still produces a reasonable result.
SAFe-style WSJF uses a relative scale for all parameters which is probably a reasonable approximation, especially as some organisations actually don’t have business cases, or at least none that are any good and/or they are not willing to do economic modelling for whatever reason. Even the use of a relative scale is likely to produce a better result.
But, instead of scaling and summing 3 parameters, it seems a lot simpler, and closer to the original concept to just relatively scale the Cost of Delay.
For example:
Absolute numbers: $100k / month
Relative scale: 3
Job duration: 5 months
Job size relative scale: 5
WSJF score = 100k / 5 = 20k
Relative scale WSJF = 3 / 5 = 0.6
WSJF can be done with relative scaling but there’s no need to add additional parameters as in SAFe-style WSJF.
What I’d like to see in SAFe WSJF
When it comes down to it, there are two basic adjustments I’d like to see in SAFe WSJF:
- Use economic modelling at the product / service / capability level to provide decision logic that can support distributed decision making.
- Simplify the parameters to only estimate cost of delay, not the current sum of user-business value, time criticality, risk reduction and/or opportunity enablement
