Problems I have with SAFe-style WSJF

I suspect that there are now a lot more people in the Agile community who are aware of Weighted Shortest Job First (WSJF) (originally from Don Reinertsen's The Principles of Product Development Flow) because of Dean Leffingwell's Agile Software Requirements and the Scaled Agile Framework (SAFe).

The Reinertsen version:

WSJF = Cost of Delay (CoD) / Duration.

The SAFe version:

WSJF = (User/Business Value + Time Value + Risk Reduction (RR) / Opportunity Enablement (OE) Value) / Job Size.

I think it's a good thing that SAFe has meant WSJF is more widely known, specifically the following concepts:

• Consideration of duration (proxied by job size) when scheduling work
• Consideration of cost of delay

However, I find some aspects of the SAFe version of WSJF problematic...

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 Value was 3, and Risk Reduction / 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 in the eyes of the customer/business"
• Time Value: "how the user value decays (or CoD will increase) over time"
• Risk Reduction / Opportunity Enablement Value: 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 / Opportunity Enablement Value 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.

For prioritising similar sized Stories, use High Delay Cost First (HDCF).

"When job durations are homogenous, do the high cost-of-delay job first." 

Don Reinertsen

For prioritising Stories, SAFe suggests a simpler formula since Time Value and Job Size are equal:

Priority = User / Business Value + Risk Reduction / Opportunity Enablement Value

This directly contradicts the fundamental insight that prioritisation should be based on how value degrades.

For example (using absolute numbers to make the point more clear),

• Story A: value is $10k, cost of delay is $1k / week
• Story B: value is $5k, cost of delay is $2.5k / week

With the SAFe formula, we will do Story A first... while if we understand Cost of Delay, we will do Story B first.

Instead, in situations where job durations are homogenous (i.e., Stories of approximately the same size), Reinertsen suggests High Delay Cost First which simply means:

Priority = Cost of Delay

SAFe-style story-level prioritisation contradicts prioritising by cost of delay.

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, time, risk reduction / opportunity enablement