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.
Get your free WSJF Excel Template
Here you’ll get the WSJF Calculator Excel Template and an easy step-by-step Guide.
Why is WSJF such a valuable agile technique?
The transition from project to product not only affects how we organise our work, but also marks a fundamental change in how IT organisations 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 weren’t so small at all, which raised 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 organisations 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 organisation 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.
This article is dedicated to the WSJF prioritization technique as it’s one of many small tools which can help to create flow. SAFe introduces the WSJF prioritization technique and suggests using it for evaluation and prioritization.
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 technique explained
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 which 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 a team of any size 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 which 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 at a much faster pace and is 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. We can now release promptly and on an almost ad hoc basis, but can’t manage to develop all of our features as quickly as we’d like to.
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.
It aims to make us aware that we are doing the right things at the right time, so 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 to generate value most quickly are given higher priority.
So, typically for SAFe, WSJF is about value and directly relates to features’ economic benefit. Working out which features have 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.
How to calculate the Cost of Delay according to SAFe?
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:
- Business Value
- Time Criticality
- Risk Reduction / Opportunity Enablement
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 to make the three factors more tangible:
Business Value:
- What is the feature’s value for the user?
- How important will the feature be for the user?
- What impact could the feature have on the product’s revenue?
Time Criticality:
- How urgent is the feature for the user’s business?
- Are there any legal or commercial deadlines for the feature (e.g., introduction of a law, the Christmas shopping period)
- Will users wait or will they look for another provider?
Risk Reduction / Opportunity Enablement
- How important is the feature to avoid risks in the future?
- Could the feature open up new business opportunities later?
Cost of Delay is calculated by adding up the three values.
Divide this by job size (i.e., complexity) to get the WSJF index.
How to calculate 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 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.
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. I do, however, recommend using StoryPoints 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 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.
To do this, we need to choose a “favourite” feature which will serve as a good base of comparison for the others and 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 favourite. In Scagile, for example, you can pin this favourite 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 favourite. This is normally sufficient, as if the favourite 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.
Further advantages of the WSJF technique
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 into a tool which 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 which 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. So, why don’t you give it a try?
Get your free WSJF Excel Template
Here you’ll get the WSJF Calculator Excel Template and an easy step-by-step Guide.
WSJF Prioritization step-by-step
