<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

By Bob Wen

When working with the Scaled Agile Framework (SAFe), you may deal with types of work that can be decomposed into Stories lasting longer than a typical Scrum iteration, while fitting within the time frame of a Program Increment (PI). It is best to classify these issues as Features. Larger-scoped business initiatives will often take a number of these Features and bundle them into Epics. If you are looking at competing Epics or Features, you may wonder what the best strategy is to prioritize the work. After all, ranking these as you would rank Stories may seem arbitrary. So what is a logical way to prioritize Epics and Features?

Donald Reinertsen advocates taking an economic view. He identifies Cost of Delay as the "one thing" to quantify in his book, The Principles of Product Development Flow. If you want to use Cost of Delay as your way of getting an idea of Return on Investment (ROI), or "bang for the buck", you need to look at that Cost of Delay divided by the effort. For this calculation, many divide Cost of Delay by Job size or duration, to produce CD3 = Cost of Delay divided by Duration. If you're looking at agile development using the Scaled Agile Framework (SAFe), you know this as Weighted Shortest Job First (WSJF).

Pricing the Cost of Delay

What is the Cost of Delay? Cost of Delay differs from straight revenue numbers.  Cost of Delay exposes how much value you stand to lose by delaying development and release for a specific period of time. Conversely, Cost of Delay shows how much revenue can be gained by developing and releasing the functionality in an Epic or Feature early.

You don't have to have to be a financial analyst to calculate Cost of Delay. If you have the Cost of Delay values in dollars available to you, you can certainly take that absolute value of the Cost of Delay for each Feature and divide by the Epic's duration to get a "true" WSJF. Otherwise, a relative calculation of WSJF will allow you to compare multiple Epics or Features by their ROI.

In their formula for WSJF, Scaled Agile identifies 3 factors for relative Cost of Delay calculations:

  • User/Business Value - Quite simply, revenue impact if delayed
  • Time Criticality - How quickly does the user/business value decay over time?
  • Risk Reduction and/or Opportunity Enablement - This is simply a placeholder for Strategic Value. Sometimes an Epic may be needed that provides no immediate User/Business value, but may needed for upcoming business strategy.

Each factor can be given a weighted value, usually done using the same Fibonnaci numbering scheme used by your Scrum teams in Estimation Poker. Summing these factors gives your relative Cost of Delay.

Dividing by Size

In the early stages of development, it may be hard to determine the exact job duration. Here, using Job Size, such as the total Estimated Story Points can serve as an adequate proxy in our WSJF calculation.

It's all Relative (and Changing)

As you begin work on an Epic or Feature, by the nature of mathematics the calculation for CD3 or WSJF will change. The denominator (job size/job duration) will decrease as more Stories are delivered. This increases the WSJF value. However, stakeholder feedback may affect the factors in the numerator, decreasing the overall WSJF. It makes sense to perform timely, regular calculations of WSJF for situations such as the following:

  • Our team didn't quite finish our Feature before the Program Increment (PI) ended. Does it make sense to continue/finish the Feature in the next PI?
  • Will we continue to recoup value by continuing development of this Epic? Or should we pivot to a different Epic that may yield greater returns?

Regular examination of WSJF values allows you to bring agility to larger scale business initiatives. Keep working on an Epic, delivering value as its Features are finished... until a "diminishing returns" point is reached. How do you know when you've reached this point? Other Epics will start having higher WSJF values and need to be worked.

Want to Use WSJF?

WSJF is not exclusive to using SAFe. If you want a logical way of prioritizing Epics in Scrum using WSJG, you may do the following:

  1. The Product Owner gathers User/Business Value, Time Criticality, and Risk Reduction/Opportunity Enablement from stakeholders
  2. Divide this by the sum of total estimated Story Points to produce a WSJF figure.

In my next blog article, I'll illustrate how Isos Technology did exactly that inside of Jira.


Managing JIRA at Scale White Paper

See More From These Topics