WSJF

Weighted Shortest Job First (WSJF) is a lightweight agile estimation technique that helps teams prioritize tasks with the highest value and the smallest size.

WSJF originates from the Scaled Agile Framework (SAFe) to help teams with prioritization and was popularized by Don Reinertsen and SAFe’s creator Dean Leffingwell.

A WSJF estimate is calculated by dividing the job size or user story size by its relative importance, which is also known as the Cost of Delay (CoD).

The importance of a task or user story may factor in time criticality, user-business value, risk reduction, or return on investment. This means teams may estimate twice on each user story or task – once to determine its size, and again to determine its importance.

According to the SAFe website, there are three components of the cost of delay:

Some teams like to develop metrics by which user-business value, time criticality or risk reduction and opportunity enablement can be quantified. Since estimates are usually subjective, many teams find value in setting some loose guidelines for teams to bear in mind.

By the end of a WSJF estimation session, your backlog will be prioritized according to the tasks that will deliver the maximum economic benefit. The higher priority tasks that are easiest to complete will sit at the top. And heavier, lower value tasks will sit near the bottom of your backlog.

WSJF is a helpful backlog prioritization technique for product development teams that want to make the biggest impact first.

Since WSJF is an estimation method, you can use any estimation scale you want. Some teams will use the Fibonacci sequence to estimate job duration or size and relative value or importance. Or you can choose your own. However, since this technique relies on calculating a WSJF score, it’s not much use to try something like t-shirt sizing, since sizes cannot be divided by each other.

WSJF is agile’s answer to the maxim “measure twice, cut once. Agile teams may use WSJF if they want to focus on prioritizing items that will have the biggest customer or business impact.

Your team will make two estimations, one for effort, and another for value. Then you’ll prioritize everything based on the sweet spots of value and effort.

For effort estimation, you’ll use the same principles from the estimated effort method of sizing. Depending on your team, you’ll think about the relative size (in story points) or the job duration (if you’re into estimating time periods).

Then you’ll use a similar method immediately after for estimating the value or the cost of delay, based on the three components above.

Once you’re done sizing tasks by effort and value, you’ll need to pick those sweet spot tickets. The WSJF process is helpful for Product Managers or Product Owners who want to focus on delivering value to end customers and building the right thing.

At the end of your agile estimation or planning poker meeting, you’ll wind up with a neat, prioritized list of tasks with the high value, low effort items sitting pretty at the top.

When estimating with WSJF, your team will use sizing scales – Fibonacci, Five fingers, T-shirt sizing, etc. – to determine how much work each task will take, and determine how much value stories will deliver to the purchaser, user, or other stakeholders.

These values on each scale are commonly referred to as story point values. Story points are purposefully abstract, which means there’s no official standard on what the number 13 represents in the Fibonacci scale.

So be prepared for some discussion as everyone comes to an agreement on effort and value estimates.

The more tasks you size, the easier sizing becomes, as you compare tasks to each other.

If someone throws a t-shirt at you, it might be hard to tell if it’s large or small without a tag. But if you’ve got two shirts and you lay them out, you can size them against each other. 

The same approach applies to value. You’ll be using a scale just like you did with effort.

Pro tip: Before you start estimating with value, have a discussion with your team on what value means:

Does value refer to what’s most valuable to the company? What’s most valuable to the team? Maybe you’re sizing features for an app and you want to prioritize things that would be most valuable to your users. Or maybe value literally means the monetary value of shipping a feature, and you want to prioritize things that make the most money.

Agreeing on value upfront is key to estimation accuracy, so make sure you’ve got everyone on the same page. 

Each time you run agile estimation meetings with the same scale, you strengthen that scale for your team. Before long, everyone will have a baseline knowledge of what each point means and you’ll sail through estimations.

Why not try using our Sprint Poker tool to estimate your stories in no-time?

Simply start a meeting, then choose Weighted Shortest Job First and your preferred sizing scales. 

Our Sprint Poker tool gives you the option to choose two different scales, but we recommend using the same scale for both the effort and value, especially when you’re first getting started.

You can start the meeting with an optional icebreaker and after that you’ll start estimating. Each team member will have two hands of cards, one for effort and one for value. They can easily swipe between the two and vote anonymously on the current task. Once everyone has voted, the facilitator can reveal the votes, and the discussion begins. After the team has agreed on effort and value, you’ll move on to the next task and repeat the process.

After you’ve got everything sized, you can send your stories back into Jira. Parabol gives you full reports on your Sprint Poker meetings, so you can chart your team’s progress, accuracy and impact on value over time.