The Weighted Shortest Job First (WSJF) technique is used to quickly and effectively prioritize jobs. As we’ll see further down, prioritizing jobs is not only key to maximising ROI, the technique is also a valuable component of lean-agile enterprise transformations.
In this article, you’ll find out not only what role WSJF prioritization plays here, but also how it works and how to implement it in practice.
Here you’ll get the WSJF Calculator Excel Template and an easy step-by-step Guide.
The transition from project to product affects how we organize our work and marks a fundamental change in how IT organizations see things. Products are perceived as a whole and we refer to their complete life cycle, whereas we used to imagine product development more as a series of smaller projects.
Sometimes the projects aren’t so small at all, which raises further questions. Agile project management introduces new techniques which allow us to broaden our outlook on product development.
The term DevOps and the cultural transformation of IT organizations that it embodies would, for example, make little sense without the change in perspective from project to product. We’re just mentioning all of this to introduce the context and set the stage for the WSJF prioritization technique.
In comparison to projects, product developments are considered on a more long-term basis: across their entire life cycle. This then has an impact on the organization which plans, develops, operates, and supports the product.
This creates, among many other things, a long-term, constant flow of features, paired with customer feedback and the use of many other valuable agile techniques, such as design thinking, OKR or others.
All of this would only be possible to a very limited extent in projects, as a great deal of domain knowledge, time, and countless feedback loops are required in order to really reach a high level, which is in itself necessary to create flow.
SAFe introduces the WSJF prioritization technique and suggests using it for evaluation and prioritization.
This article is dedicated to this technique as it’s one of many small tools which can help create flow.
I’m not entirely sure whether SAFe actually invented the technique, but that doesn’t really matter here. The WSJF technique is relatively easy to integrate into SAFe, meaning that it can be a hefty tool (not to stray from the metaphor) but also lends itself to use within other frameworks. This is similar to, for example, design thinking approaches or even scrum as an implementation method.
WSJF stands for “weighted shortest job first” and is designed to give us a better idea of which jobs we should do first, so we can accurately prioritize a series of features that are waiting to be implemented.
Prioritization is also certainly easier for projects than for products, which is why this technique exists in the context of the above-mentioned project-to-product transition.
Projects generally have a fixed framework and (planned) duration, but I think that’s obvious and requires no further development. We should, however, explore the task of prioritization somewhat further before I explain the WSJF technique and its application, as prioritization is often severely underestimated.
Prioritization is a difficult task both practically and mentally.
Because, above all, prioritization means deciding not to do something (now). .. This means that it immediately awakens fears of loss in product owners and stakeholders.
I know what I’m talking about because as a product owner and stakeholder at Scagile, I have many more ideas than any size team could even implement. It’s often frustrating to constantly hear “no way, that’s never going to happen in this PI” from development teams. And this is a never-ending story that is repeated in each PI. But at the same time, we want to develop an outstanding product and urgently need the feature. The market seems to be evolving much faster and assimilating new features even more quickly than we can develop them.
Beloved technical advancements such as Continuous Integration, Continuous Deployment, and Release on Demand just make the whole thing even more frustrating.
Prioritization therefore also means being extremely clear about the object, i.e., the feature which needs to be prioritized – this isn’t always easy either.
So, WSJF prioritization is meant to help us overcome our frustration and ensure that as product owners and stakeholders we are, if not completely happy, at least satisfied.
WSJF aims to make us aware that we are doing the right things at the right time,and remaining efficient.
I got to know WSJF prioritization as a very powerful and effective tool as part of SAFe. This is why we’ve fully integrated the technique at Scagile and even elaborated on it somewhat.
As stated above, WSJF stands for “weighted shortest job first” which basically means that features with the potential togenerate value most quickly are given higher priority.
So, typically for SAFe, WSJF is about the value and directly relates to the features’ economic benefit. Working out which features have the potential to quickly generate value doesn’t just mean figuring out what you can get done quickly, but also calculating the feature’s exact value.
WSJF Index = CoD*/Job Size
*CoD = Business Value + Time Criticality + Risk Reduction/OE
This question can also be reversed, which brings us a step closer to explaining the technique. The question is what will a feature cost me if I get it late or never.
WSJF’s first aim is therefore to calculate the so-called “Cost of Delay”. This question nicely ties into our prioritization problem of having to decide not to do something.
Calculating Cost of Delay makes sense because features’ cost comes not only from their business value. For example, GDPR conformity certainly has no particular business value, but not implementing it in time can become very expensive.
Cost of Delay is therefore calculated using three values:
The latter attempts to estimate what else the feature can do for us in the future. It could, for example, give us a long-term advantage over competitors, elaborate our USP or help us to avoid risks in the event of future restructurations.
The following questions can help make the three factors more tangible:
The Cost of Delay is calculated by adding up the three values. Divide this by job size (i.e., complexity) to get the WSJF index.
Job size represents the job’s complexity, as this influences effort and duration. Effort and duration should not be directly calculated here, as they’re more relevant to the characteristics of the feature team. A characteristic of the feature should, however, be estimated at this point, and that’s complexity.
Because when requests are being evaluated, it’s often not yet clear which team will implement the feature, or the team’s velocity is unknown or subject to variation. Estimation isn’t an exact science anyway and shouldn’t be made more difficult than it already is.
This facilitates – and I assume shortens – in many cases the planning process for the coming iteration (sprint, PI).
A comparative estimation is therefore made to help evaluate all four dimensions.
We already know about this from estimating stories and features using Story Points. You can use whatever metric you like here: a scale of 1-10, t-shirt sizes or anything else.
Agile teams usually use StoryPoints already, so know how they work. In particular, this then makes it easier to calculate the job size in relation to the team’s velocity in order to better estimate duration, as long as all teams are using a synchronised (standardised) scale. Of course, other estimation techniques such as “magic estimation” can absolutely be used as well.
This evaluation is then especially effective if calculated using a table for the whole feature, whereby we first calculate the business value for all features in one column, then time criticality in the next column, then both other values in their own, separate columns.
I do, however, recommend using Story Points with the appropriate Fibonacci sequence:
(0,1,2,3,5,8,13,20,40,100).
Agile teams usually use StoryPoints already, so know how they work. In particular, this then makes it easier to calculate the job size in relation to the team’s velocity in order to better estimate duration, as long as all teams are using a synchronized (standardized) scale. Of course, other estimation techniques such as “magic estimation” can absolutely be used as well.
This evaluation is then especially effective if calculated using a table for the whole feature, whereby we first calculate the business value for all features in one column, then time criticality in the next column, then both other values in their own, separate columns.
We then give it a score for, for example, business value. We need to be able to accurately estimate its value which should ideally be medium-sized. Every other feature will then be compared to this favorite. In Scagile, for example, you can pin this favorite in order to reuse it in every future PI.
To compare the features, I mainly ask whether the current feature’s business value is larger, much larger, smaller, or much smaller than that of the favorite. This is normally sufficient, as if the favorite has a medium-sized value (e.g., 8 or 13), smaller can be 5 or 3, much smaller 1 or 2, larger 20, and much larger 40 or even 100.
Evaluating in this way is very quick and generally not too difficult. For many projects, this made it possible to evaluate entire backlogs with several tens or even hundreds of large jobs with a development time of well over a year in under 2 hours. That’s pretty reasonable for any team.
A further significant advantage of this technique is that it brings people from different parts of both IT and business together to discuss your needs. Instead of being a decision made solely by stakeholders, prioritization, therefore, requires real teamwork and creates transparency.
Business value is, of course, mainly evaluated by product or marketing departments, whereas legal and compliance often deal with time criticality, strategic management with risk reduction/opportunity enablement, and feature teams, of course, with job size.
This makes the WSJF technique a tool that not only alleviates our frustration around prioritization but also simultaneously promotes our agile culture.
If we use a cool tool to do this, it can even be fun, or at least interesting, and certainly not tedious.
There are certainly other factors that ought to be taken into account alongside the WSJF index for the final calculation, such as, for example, dependencies between the features.
The WSJF technique and index, therefore, provide an informed suggestion.
In my experience, the technique’s strength comes from its ability to provide clear, debatable, and assessable prioritization criteria, for an efficiently structured prioritization process and necessary transparency within change and demand management.
My recommendation is to take the three Cost of Delay factors into account when describing the feature.
This makes it much easier to pitch the requirements and those requesting the feature can account for the Cost of Delay from the beginning. It is also easier to write the brief as you’ll already have a helpful template for the requirements you’ll be describing.
We’ve also seen that stakeholders speak to their feature teams more often when writing their requirements, in order to get an idea of the job size. This massively promotes lean-agile culture, often even more so than multiple team-building events. The WSJF is also very easy and quick to implement with little effort.
Here you’ll get the WSJF Calculator Excel Template and an easy step-by-step Guide.
The WSJF calculator is directly integrated in the scagile project management app.
The success of agile projects is directly related to communication! Leonardo DiCaprio in his role in ‘Inception’ will be your Scrum Coach today and show how to communicate successfully in Scrum. Sounds adventurous? It is 🙂 Read more …
What is it that renders the role of the scrum product owner so problematic and how should it be designed to allow an agile transformation to succeed?
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
