WSJF for backlog prioritization

Weighted Shortest Job First (WSJF) is a prioritization method, introduced by Donald Reinertsen, to sequence jobs such as epics, initiatives or features (but could also potentially be used to prioritize smaller backlog items) in order to produce maximum economic benefit.[1] Based on its original definition, WSJF is calculated by dividing the Cost of Delay (CoD) by the job duration, using their actual values. The following formula is used [1]:

WSJF is a widely used prioritization method in many medium and large enterprises, often seen in a scaled agile environment using the Scale Agile Framework (SAFe). However, unlike the original model by Don Reinertsen, SAFe relies on relative estimation using a modified Fibonacci sequence when calculating the WSJF in order to avoid worrying and wasting unnecessary time in calculating absolute numbers.[2]

Let's now look in more detail the top part of the equation (Cost of Delay), the way it is prescribed by SAFe.

The Cost of Delay (CoD) is a tactic that helps to communicate and prioritize development decisions by calculating the impact of time on value creation. Put in monetary terms, the Cost of Delay (CoD) is essentially the money that will be lost by delaying or not doing a job for a period of time. But how do we calculate the cost of delay in practice? The Cost of Delay (CoD) is the sum of three components: User-Business Value, Time Criticality and Risk Reduction and/or Opportunity Enablement [2]:

User-Business Value: This component represents relative value (using modified Fibonacci sequence) to the customer or to the business itself.[2] The value is rather subjective, but it can be connected to revenue, impact or other metrics already explained in my last article. But what is important is to make sure the value of each feature or item is estimated relative to the others and whoever estimates the user or business value does not simply choose the highest possible number.

Time Criticality: This component indicates how critical a certain feature (or another backlog item) is. Is there a specific external or critical internal deadline? Or are there any milestones on the critical path that will be impacted if this feature is delayed?[2] Is it a legal requirement with a specific due date?

Risk Reduction and/or Opportunity Enablement: Does the feature mitigate a risk (e.g. data center or hardware failure)? Or does it enable a new business opportunity (e.g. entry into an additional market)?[2]

Now we’ve covered the top part of the formula (Cost of Delay). Let’s now look at the bottom part - job duration.

Job duration can be very difficult to calculate, especially early on when we might not know who is going to do the work. Any dependencies or specialized skillset of engineers/developers can increase the duration of a job. As a result, job size tend to be used as a proxy for job duration in SAFe.[2] Calculating job size in order to estimate the total effort of work to deliver a feature or an epic is done using relative estimation with the modified Fibonacci sequence.

The final step of the process is to calculate the Weighted Shortest Job First (WSJF) score. The higher score you have for a feature, the higher it should sit on your backlog. Figure 1 below shows the recommended approach on how exactly WSJF score is calculated for a job (e.g. for a feature) and how you compare jobs and decide how to rank them.[2]

Figure 1: Calculation of WSJF[2]

Let’s take the website of an airline as a practical example and assume we want to prioritize two features – 1/making the list of flight results on the website more relevant for the customers, and 2/reducing the time it takes for the customer to obtain the search results. We score these two features using WSJF. Imagine the calculations show that the first feature has total cost of delay of 22 and a job size of 13. That makes WSJF score of 1.69 for the first feature. The cost of delay for the second feature is 5 (a lot lower than first feature) and has a job size of 2 (it takes a lot less effort to implement). Hence, WSJF score of the second feature is 2.5. In that case it makes sense to implement the second feature first due to its higher WSJF score. Therefore, we can conclude that even though higher cost of delay score often means higher position on your WSJF list, this is very much dependent on the total effort it takes to implement the feature (or epic, or another backlog item). Because big (but important) features might never get sufficient priority to get implemented, simply because of the effort it takes to implement them, the WSJF model encourages splitting large work packages (i.e. the art of slicing work) into multiple smaller work items to allow them to compete against other small items.

Let’s now explore the advantages and disadvantages of Weighted Shortest Job First method.

• Promotes completeness and consistency. Due to the prescribed detailed calculation, stakeholders can expect reliable and predictable results with this prioritization method.
• Brings clarity and understanding. WSJF is a great tool for (portfolio management) teams to start to understand each other. The model brings clarity by pinpointing specific items that should be tackled first and provides clear insights on how the prioritization decision was made.
• Takes into account technology constraints and implementation effort. This prioritization technique considers not only cost of delay (value, but also time criticality and risk reduction/opportunity enablement), but also takes into account the technical aspect. It tells us (in relative terms) how difficult and time consuming the development of each feature would be.
• Focuses on increasing return on investment while making efficient use of human resources (hence suitable for organizations with limited resources).

Even though WSJF is one of the most popular prioritization techniques out there and is widely used by many (chief) product owners and product managers in a scaled environment, it is important to note that this prioritization method also has its downsides.

• Time-consuming calculations. This is one of the main issues with the WSJF prioritization method. If a product owner or a product manager has hundreds of backlog items (e.g. for a mature product), then they have to spend significant time to prioritize them using this method. It also takes time to estimate the values (albeit relative) for each of the components of WSJF.
• Inhibits (big) complex initiatives/projects. If the business has a sustainable idea, but the WSJF calculations do not show a high score to make it to the top of the list, its implementation will most certainly be postponed to a later stage. This makes the method a bit restrictive in implementing considerable, long-term, business ideas. Overall, similar to the Value vs Effort method, we can say that WSJF method prioritizes short wins over big and time-consuming projects.
• Summing up relative estimations of different parameters could sometimes lead to suboptimal results. Using relative scales rather than absolute numbers avoids unnecessary precision and tend to be easier for people to estimate. However, calculating Cost of Delay by summing up relative numbers of business/customer value and time criticality could sometimes lead to bad decisions or suboptimal job sequencing, as we compare items that move different economic indicators. This could create problems unless the relative scales are set up right and aligned with all stakeholders. Since it is hard to align all metrics and assumptions to achieve balance, the method has room for errors and is not recommended for important cut-off decisions.
• Subjectivity. Similar to the other agile prioritization methods, WSJF’s score are subjective, meaning that the assessment is only as good as the ones giving the scores.
• WSJF makes a few important assumptions worth highlighting:
  • WSJF assumes that the critical resources on a project are the same and they are all busy during the entire duration of the project. This can be challenging, especially in hardware development companies, in which critical resources may often change over the course of the project. One way to tackle this situation would be not to have many teams formed around specific projects and whose team members are constantly changing during the course of the development. Rather have a larger stable (cross-functional) agile team of teams with clear purpose and ownership for part of the product/solution.
  • WSJF does not take into account specialized human resources (e.g. employees with a specialized skillset or expertise/competence in a specific area). Those resources will in general be assigned to work on the highest priority items depriving lowest priority items from moving forward (in case their contribution is also needed there).
    

Weighted Shortest Job First (WSJF) model can be used for prioritizing any piece of work – from helping teams decide what story to work on next to helping a company’s management decide what major initiatives or epics to fund, and anything in between. WSJF is a great technique to assess and create minimum marketable features, i.e. small features that can be developed quickly and deliver significant value to customers.

However, product people should not always rely on WSJF when estimating work on their backlogs. For example, there are often items on a backlog which are easier to implement by default without spending significant time in long discussions (and searching for data) and being surprised in the end if WSJF score turns out not to be high enough. Such items are typically due to regulatory compliance requirements and I have encountered examples in industries such as banking and energy, but they can also be found on military, food and drug projects. Regulatory requirements due to compliance are often non-negotiable and have strict deadlines, so choosing to ignore, delay or skip them is usually not an option since it will result in the organization not being paid or the product not being accepted and used. Of course, if there are many mandatory regulatory items related to compliance, those should still be prioritized, but perhaps time criticality is the most important component to consider there.

In my next, and final, article in the series on prioritization methods and techniques, I will compare all the prioritization methods covered in my articles so far. Meanwhile, if you want to know more about prioritizing using the WSJF model, please feel free to contact me.

[1] Reinertsen, Don (2009). Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.

[2] Scaled Agile Framework (2020, February 11). Weighted Shortest Job First. Retrieved from https://www.scaledagileframework.com/wsjf/