Weighted Shortest Job First: Using and Calculating WSJF

Defining the Weighted Shortest Job First Model

Dean Leffingwell published various books on scaling software agility and agile software requirements, and created the Scaled Agile Framework (SAFe).

SAFe includes a section about the WSJF model, which is commonly used by agile teams to prioritize tasks. For a DevOps team, it’s a great method for sorting initiatives based on priority as a function of the business value they add. In other words, a DevOps team can maximize the value they deliver for each sprint.

The agile framework describes sprints as a great way to continuously create value in short cycles. However, it’s not clear how to prioritize tasks that are included in each sprint. To bring this clarity, the WSJF model helps teams pinpoint tasks that should be tackled first.

Therefore, the WSJF model helps DevOps teams manage a continuous stream of tasks. It’s not always straightforward to know which tasks to prioritize. The team has to take into account the business value a particular project returns for the organization, the resources needed to tackle the initiative, and other factors.

Let’s take a look at various benefits your team enjoys when utilizing the WSJF model.

Benefits of the Weighted Shortest Job First Model

Here are three reasons why the WSJF model is important for an organization’s prioritizing efforts.

1. More Accurate Prioritization Scores

First of all, the WSJF model provides your organization with a systematic approach to calculating scores for initiatives. You become better and better at prioritizing initiatives the more you practice it. You learn things like what tasks deliver what kind of business value, and the relative risk of one initiative versus another. This means you’ll get more accurate scores the more you use WSJF. In the end, the goal is to make better-informed decisions.

2. Better Resource Allocation

Knowing what efforts to prioritize allows you to better allocate resources to get the most business value. For example, based on WSJF scores, your DevOps team may decide to prioritize implementing Kubernetes to improve your company’s ability to scale its services. Therefore, your product manager knows they’ll have to allocate resources to support this project during the current and upcoming sprints. In other words, your team can better allocate resources to maximize productivity and value.

3. Easier Change Management

Change is inevitable. Priorities change and new initiatives are created. Therefore, the WSJF model allows you to recalculate scores when new initiatives are added or other changes occur at your company, and estimate the new urgency of each task.

For example, your DevOps team decides to start using Kubernetes as mentioned before, but should you include this new initiative in the next sprint? The WSJF model helps you calculate a prioritization score for this project so you’ll know whether including it the next sprint or the one after makes more sense.

How To Calculate the WSJF Score

The weighted shortest job first score consists of two inputs: cost of delay and job duration or job size. The formula is surprisingly simple, just divide the cost of delay score by the score for the job duration or size.

cost of delay / job duration

If you’re wondering how to calculate these scores for an initiative, let’s move on to the next section!

1. Calculate the Cost of Delay

Now that we know the formula for calculating the WSJF score, let’s learn how to calculate the cost of delay. According to the WSJF model, the cost of delay consists of three elements:

• Business value: This is the value for the user or the business upon completion of an initiative.

• Time criticality of a project: Is there a deadline? Will you lose customers if you delay?

• Risk reduction or opportunity creation: For example, implementing Kubernetes helps your organization scale when demand increases. This is a clear opportunity for your organization.

You need to give a score for each element using a scale from 1 to 10. Then, combine the individual scores to compute the sum for all three elements. This sum represents your cost of delay.

Let’s look at an example. Imagine you’ve just started a new company and urgently need a website to find clients. In this case, your scoring may look like this:

• Business value: 9

• Time criticality: 8

• Opportunity enablement: 6

As you can see, here, a website creates new opportunities, but we would still need additional marketing efforts to boost the website. That’s the reason why the opportunity enablement criterion only got a score of 6: the website itself presents some opportunity, but without marketing its effect is minimal. In total, we end up with a cost of delay score of 23.

Now let’s calculate the job duration.

2. Calculate the Job Duration or Job Size

You can choose to calculate the job duration as a timespan, such as 5 weeks or 3 months. On a scale of 1 to 10, a 5-week project might score a 3, while a 3-month project might score 8.

Or you can approach the WSJF formula in terms of job size. Here, you give a relative score for each project depending on the job’s complexity and its size, on a scale of 1 to 10. So a smaller, less complex job might score a 2 and a bigger, more complex job might receive a score of 9.

Of course, this is a more subjective measurement. Calculating a job duration is also not 100% accurate; it depends on your resource levels, employees’ skills, and many other factors.

3. Divide Cost of Delay by Job Duration

In the last step, you divide one score by the other. Make sure you use a consistent scale (like 1–10) for calculating both values, otherwise, you end up with incorrect results.

Let’s look at our DevOps team example where we wanted to build a website. The cost of delay score for that initiative was 23. Now, we estimate that the job size is 5 on a scale of 1–10. This gives us a final score of (23 / 5) = 4.6.

Now assume you have a project with a cost of delay score of 19 and a job size of 2. Here, the final WSJF score is 9.5. This project has a higher WSJF score than building a website did, and therefore, this project would have higher priority.

In other words, projects with a short duration will score high using the WSJF model. The same is true for projects with a high cost of delay.

A Problem With WSJF Model

There’s one obvious problem with the WSJF model. The model doesn’t take into account the relative weight, for a particular business, of the three elements that make up the cost of delay.

For example, business value may matter more for a particular organization than other elements, whereas for another company, time criticality or risk reduction may matter more. But the WSJF model treats each element equally. You can, however, apply weights to the elements by multiplying each score by a different factor.

Wrapping Up

The weighted shortest job First model helps software development teams prioritize tasks to optimize the value they deliver. The WSJF model can be easily implemented as it only relies on two input parameters: cost of delay and job duration or job size. However, make sure to always use the same scale to calculate scores. Otherwise, you’ll end up with scores you can’t compare to further prioritize tasks.

Once you’ve prioritized your initiatives, value stream management (VSM) can help your team to consistently improve value for each sprint, You can use Plutora’s value stream management platform to find opportunities for improvement. By combining the WSJF model with VSM to increase the business value from the development phase up to product delivery to your customers, your team can maximize the returned value for each sprint.