Often, what really matters in life is not the precise path you end up taking, but the criteria you used to arrive at that conclusion.
Just as knowing yourself and why you do certain things can increase our self-awareness, having sound criteria for prioritizing tasks can teach you a lot about your team and your organizational strengths.
Before explaining why Weighted Shortest Job First matters, let’s look at a simple definition of the approach. Later, we’ll outline the formula for calculating WSJF and examine its use against practical challenges that commonly emerge in product management and other business functions.
As the name suggests, Weighted Shortest Job First has two key variables to classify tasks: the importance of the job to the overall project (“weight[ed]”) and its length (“shortest”). These parameters are combined and function as a prioritization tool (“first”).
In short, WSJF means that a task’s relevance and time allocation will define its order in the sequence.
In traditional, more hierarchical workplaces, the task-allocation methodology is straightforward. Bosses, business cultures, and simple force of habit usually decide what gets done first. However, ever since the digital revolution transformed our lives and jobs, leaner and more collaborative approaches have emerged to make the most of these technologies.
In particular, the principles of agile software development (first outlined in 2001’s influential Agile Manifeso) has spread to basically all other sectors of the economy. In agile, individuals and interactions, continuous product development, customer preferences, and adaptability take center ground.
The agile principles are reflected in the Scaled Agile Framework (SAFe), one of the most popular agile approaches. SAFe reflects the need for further speed, monitoring capabilities, and quality guarantees across digital products.
While SAFe can be applied to entire companies and even whole economies, its seven competencies are usually envisioned in the context of smaller startups, firm divisions, and project-related teams.
As you might have already guessed, the seven SAFe/agile competencies are highly dependent on viable prioritization criteria like WSJF.
The seven agile competencies are:
Team and technical agility refers to the human capital in your projects and their training in Agile techniques. They will rely on tools such as WSJF to understand why and how milestones are organized.
Agile and product delivery refers to the product (good or service) development approach, by which there is a continuous cycle of exploration, integration, and deployment. There will be no way of understanding dependencies and need without WSJF and equivalent measuring frameworks.
This refers to the institutional context surrounding your teams. Think of how suppliers must be engaged in time to acquire vital product components. Here, WSJF is essential to reveal pathways to adjust to project needs.
When your team, division, or firm begins growing, it’s often difficult to understand how your various product offerings interact with each other. WSJF help you understand which dependencies are useful and which are capital and time-consuming.
How quickly are you able to respond to change, both positive and negative? There are different ways of measuring time, but WSJF is particularly well-suited to agile because it combines task relevance with length.
Similarly, this refers to the inherent need for your team and your product to acquire new knowledge once threats or opportunities have been identified. WSJF can be helpful in identifying those skills that are more urgent and important for the task at hand.
Finally, managers in agile are different from other managers. Their steering must not be top-down and distant, but horizontal and evidence-based. WSJF offers a consistent approach to ensure decisions are understood and backed by teams.
You don’t need to attend business school or know enterprise capability theory to understand a company’s key constraints: money and time. Time is money, as they say, which is why making the most of your time always makes economic sense.
In these days of agile enterprises, though, the way we perceive time also matters.
For example, perhaps the standard way of looking at a project is linear: we start with research, turn to development, then test, deploy, and gather feedback. Alternatively, you could observe product development as an infinite cycle in which you first seek feedback on a prototype before actually researching and developing a scalable solution.
WSJF’s consideration of both task time and relevance makes it applicable to both linear and cyclical-style project development. While this might be the case with other formulas, WSJF stands apart from other prioritization frameworks for its emphasis on objectivity, action, and optimization.
Regarding objectivity, WSJF provides a clear, transparent metric for stakeholders to understand why and when their needs will be satisfied. Obviously, most teams in most situations will ideally want:
WSJF’s formula, can sharply reduce the coordination failures and conflicts that emerge from this struggle for resources. If everyone is aware of it, teams will learn to adjust their expectations and focus on their tasks.
WSJF’s bias for action is crucial. Any long-term task can fall victim to the sunk cost fallacy and similar cognitive biases. In short, this means you feel you cannot abandon a particular course of action because you have already spent substantial time or resources on it.
As anyone who has suffered through a long and boring movie at the cinema will tell you, the rational action is to reassess whether it truly is useful to keep going in the same direction.
Past investments should be no guide for future ones. Rather, the WSJF formula enables you to elucidate whether a particular task is still worth the expense or whether resources should be reoriented toward a more urgent and important milestone. That way, you have a rational guideline to direct your energies.
Optimization is essential when dealing with digital products and the way developers and consumers interact with each other. Without an adequate compass, leaders are liable to impose vanity metrics onto their teams, and vanity metrics often lead to vanity features or products — that is, bad information that results in bad or inconsistent elements in your full product portfolio.
WSJF focuses leader and team priorities on what really matters: task importance and costs. While there are many other reasons that justify choices in life, these are the two most relevant ones when you are in the office.
While objectivity, action, and optimization are expected contributions when WSJF works well, there are also dangerous pitfalls that emerge in the discussion and application of this methodology. Most of them are connected to the process of discovering the values used for the formula.
The formula for calculating WSJF is as follows:
WSJF = cost of delay / estimated job size or time
How are the values assigned to each side? Let’s unpack both items.
The cost of delay figure is a composite number. It is the sum of the following three components:
Since products and features can be for internal or external consumption, value here can refer both to customers and to company stakeholders.
For example, you might have to decide between cleaning a bunch of new data for the UX team or focusing on implementing your new brand image across your app.
Time criticality refers to basically any task element connected to deadlines, pathways, and dependencies. These can be material or ideational.
For example, a sales team might rely on you to complete a new website section so they can start a campaign. But it is also possible that your manager might simply think it would be beneficial to show other stakeholders your progress.
There are two ways to perceive this factor: negatively or positively. You can judge projects by their ability to secure your company’s position in the long run — i.e., protect against risk. Or, you can judge them by their potential to open new markets and initiatives — i.e., unlock new opportunities.
The three factors described above have two main value assignation strategies: job size or duration.
Job size or duration is a trait that can be adjusted to your priorities. In certain activities, such as the creation of graphics for a product release, it is easy to measure quantities and even exact timing until completion once key principles have been established. Here, you might be able to easily assign numbers of hours, days, or months to a task to produce
At the same time, there are many other tasks that are more abstract. In developing the sign-up form for a new feature, for example, you might have different priorities at play — usability, data depth, personalization, etc. Experimenting between different versions until you arrive at an acceptable resolution might take longer than expected.
Keep reading to learn how to assign value when it’s unclear or difficult to estimate job size/duration.
There are two widely used approaches to assigning value, in addition to a third WSJF approach where this factor is not important. In both cases, the components that comprise the cost of delay figure are added up and divided by job size, whereby each feature, product, or project receives a score.
The element with the highest score should be the highest priority, and so on. It’s always the best practice to run this exercise several times and with different teams to normalize the scores.
The first way to solve the formula is with exact numbers. This usually means either your organization or the product management software you’re using has built-in methodologies to calculate value, criticality, risk reduction, and job size. Different organizations and programs have different criteria, but their outcome is the same.
The other way is to come up with these values yourself and then spread the use across the organization.
In many cases, WSJF users simply rely on the classic Fibonacci sequence, where each successive number results from summing up the two preceding: 1, 2, 3, 5, 8, 13, 21…
These numbers are just random estimates, but their separation is wide enough to allow for a useful classification. It’s usually best to begin with 1 as the lowest number and then assign a singular value to each of the other elements. You can use this method for both sides of the formula and to normalize the result to obtain a suitable WSJF hierarchy.
One of the loudest critiques of the WSJF methodology is related to these values and their use in the formula. Allocating value, risk, and time is a notoriously difficult thing to do when it comes to our day-to-day activities (e.g., cleaning our car, renewing our passport). It is even more complex in a company with multiple moving parts.
This is where an elegant solution emerges. Instead of thinking of WSJF exclusively through the formula, you can simplify and use it as a qualitative tool. This is particularly useful at the start of the project. You can do it with a simple table like this:
| Qualitative (non-math) WSJF | Large job size | Light job size |
| High cost of delay | Highest priority; begin with this and focus most resources on task | High priority; focus moderate resources on task |
| Low cost of delay | Low priority; adjust most resources for use at later stage | Lowest priority; leave aside for future completion |
While you might find it difficult to assign the correct Fibonacci value, with the qualitative or non-math WSJF, you only operate with four boxes. You can rely on rough assumptions to classify tasks on your project. This is particularly useful when exploring a new market or product.
Once you have a better idea of your goals and capabilities, you can try the mathematical WSJF formula to provide a better guide for your team to prioritize tasks.
WSJF is a task prioritization methodology that is particularly useful for teams using agile methodologies. It focuses attention on crucial tasks with objectivity, a bias for action, and optimization of resources.
The standard WSJF formula is obtained by dividing cost of delay (CoD) by job size or time (JST). That is, WSJF = CoD/JST, where CoD refers to user value, time criticality, and risk reduction and JST represents the time or other requirements involved in the task. If you don’t have exact values, you can rely on the Fibonacci sequence to assign approximate numbers, starting with the lowest at 1.
For those who are less mathematically inclined, WSJF also works as a qualitative tool. Particularly at early stages of product or feature development, it is useful to build a four-area matrix with cost of delay and time as general variables that can really help with guiding managers and teams.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
