Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to prioritize your backlog using weighted shortest job first

Matthew Heusser Managing Consultant, Excelon Development
Weight set

Weighted shortest job first, or WSJF, is an agile backlog prioritization technique that seems easy enough on the surface. It means that you do the most valuable thing first, where relative value is equal to the pure value divided by the size of the job.

The wheels don’t fall off the idea until you actually try it.

To actually implement WSJF, we’ll determine the type of weight first, then build the economic model, calculate the weight and effort for each job, and, finally, build a spreadsheet. The spreadsheet itself is only half the process—the actual selection and portfolio work uses the spreadsheet as an input, not a final result.

Let’s get started.

First determine the type of weight

WSJF is a strategy for prioritizing the implementations of product features according to their weight (i.e., their numerical value of importance calculated by stakeholders) divided by the effort (the length of a job). There are many different ways to calculate weighting and effort, but the most common method, is cost of delay divided by duration (CD3).

  • CD3 uses the cost of delay as the weight and divides that by the length of a job.

If cost of delay will be variable, consider time horizon, which views the entire value of the project over a time window. The higher the level of planning, the longer the window. We typically recommend a three-to-five-year window at the portfolio level.

  • Time horizon considers the entire value of a project generated over a three-to-five-year period.

A third style of weighting is the SAFe-style.

  • SAFe-style weighting involves the portfolio team picking subjective ratings from 1 to 20 for time criticality, cost savings (or revenue increased), and regulatory compliance.

These numbers balance the three factors but are not tied to actual dollar amounts.

Generally speaking, weights tied to revenue impact (at the right of the graph below) will lead to better decisions. At the same time, they will require more effort to get—if that information is available at all. The challenge is to pick a weight that trades off effort and reward.

Source: Better BackLog Prioritization

Get a list of “jobs”

At the portfolio level, jobs are potential investments for the company to make. That could include new products, cost-saving initiatives, keeping the lights on, new infrastructure, and more.

The key issues for each job are:

  • Project name
  • Sponsor
  • Core considerations

Core considerations are not numbers, but key drivers for the project. Examples could include:

  • Regulatory compliance required by a specific date
  • Parts of the company's vision and values for the next five years
  • Alignment with a strategic priority
  • Replacement of a legacy product with a declining revenue base

While not strictly a part of WSJF, we will come back to core considerations later.

Build the economic model

Once we’ve picked a weighting method, we need to find out the values for each project using that method. That means gathering data. If the weighting method is cost of delay, we need to find the dollar value for the cost of delay. To find the dollar value of a given project, you can:

  • Look at similar projects and see how much revenue they generated
  • Find out the revenue that will be generated if deals contingent to the creation of a feature are closed
  • Research customer retention predictions from a feature and the revenue generated from those customers
  • Calculate expected penalties or fines for noncompliance
  • Use the existing revenue of the business as the dollar value for “keeping the lights on” jobs
  • Try numerous other custom methods that apply to your situation

The economic model should also include the job size, which is generally measured in person-months, but it can also be measured in pure months. The key will be to pick a number that allows more accurate decisions than the company had before. The cost of services, support, physical servers, and cloud services should also be a part of the economic model. 

Gather the weight for each job

Now the hard part: assigning a numerical value for the value of each job.

  • With CD3, this is the top-line revenue growth (or savings) possible with the new initiative (usually per month).
  • Over a time horizon, this is the expected profit (or savings) in the time period, minus the cost to do the work.
  • With SAFe-style weighting, a small group of leaders assigns values for time criticality, revenue change, and regulatory compliance, all on a Fibonacci sequence from 1 to 20.

For a large enough organization, the ideal model is to have a single portfolio manager (the “guardian of the spreadsheet”) gather the numbers from the prospective business sponsors. Time horizon and CD3 work well at this, since the sponsor can be held to predictions after the fact.

This won’t work for SAFe, because all the competing business leaders will be tempted to inflate their scores without consequence. Instead of a single vote, you need a consensus, or at least average, that represents relative-peers.

In some cases, you won’t be able to get numbers, which might mean going back and choosing a different economic model. In general, start with the far right side of the BackLog Prioritization graph, and move left if the data is not available.

The basic formula is:

WSJF = value divided by job size

Now we'll figure out the denominator.

Gather the size of each job

The job size was determined during the economic modeling, so this portion should simply involve honing your estimates for each project. Having the sponsors provide these numbers is a realistic option, as long as there is feedback over time. Once the company completes its first project decided on by WSJF, circle back and see if the predicted duration matches the actual duration.

The great thing about this math is that even if the estimates are off, as long as they are generally off by an equal amount (for example, all projects are projected at 75 percent actual effort), the numbers will average out.

The main challenge will probably be the widely varying project sizes. In his book Principles of Product Development Flow, Don Reinertsen suggests that larger projects tend to be “later” (overly optimistic) by an increasing percentage on average. A larger percentage of a larger project means much larger schedule slips, so track schedule slips carefully.

The best way to manage this risk is to manage similar-sized projects at the appropriate level. A portfolio dealing with wildly different-sized projects may simply defer some resources (perhaps 20 percent) into a “small projects” bucket, which works as its own WSJF portfolio, or else break down larger projects into a smaller size.

Build the spreadsheet

Your spreadsheet should have six columns: Project name, sponsor, core considerations, weight, and job size are the first five. The sixth column, for weighted value, is calculated as weight divided by job size.

Add the column, then sort the spreadsheet with the most valuable projects first, and you have a WSJF spreadsheet. That isn’t enough to organize the entire IT department, but it is a good start.

Troy Magennis, the principal consultant at Focused Objective, has created a template for WSJF and released it under creative commons; see if it will work for you.

Consider alternative weights

Both Joe Vallone and Adam Yuret are quick to suggest the weaknesses of a single spreadsheet, preferring a balanced approach with multiple metrics.

If possible, create a different spreadsheet with a different weighting. If you're doing SAFE-style WSJF, try to get some actual revenue or cost-saving predictions. Or try pure cost of delay divided by duration, looking only at how long projects will take, not how many people they will need.

A full, detailed analysis would consider many different factors, only some of which would be available for each project. This looks more like a war room: multiple spreadsheets and data on poster boards all over the room.

For the time being, just try to create two different spreadsheets. The comparisons between the two numbers may create some eye-popping exceptions.

Once the spreadsheet is done, it’s time to dig into the details.

Consider intangibles

The top two projects might add up to more than 100 percent of the company. Or they might require the same skills, meaning the IT department might not have enough people with those skills. The projects might require outside contractors or additional training. The company might need to replace existing systems that are declining in revenue or need to diversify. An infrastructure project that appears to be low-return might be required to enable future projects that have higher returns, which you can think of as “cascading cost of delay.”

Once the spreadsheet is done, picking the actual projects is a little bit like putting puzzle pieces together. It will be time to come back to those core considerations, get some core decision makers in a room, and come to a consensus. The process will not be “one and done” either; think of it as narrowing uncertainty over time.

WSJF: Select the projects to fund

Implementing the ideal portfolio is likely to be a challenge because of the existing projects in flight. Most organizations I meet with are scheduled on paper to be running at 90 percent to 120 percent of capacity already, with work planned out into the future. Shifting to WSJF means waiting for a project to finish, then plugging in the best project to fill in the gap. That might not be the top of the spreadsheet, due to intangibles and staffing.

Once the first project is funded, then congratulations, the real work can begin. Now we need to continually monitor the list, adding new jobs, deleting the bad ideas, and updating weight and job size as new information becomes available. As projects end, fund the next project that makes sense while monitoring to see if the implementation is delivering better outcomes than whatever process you used before.

Note about source: Better Backlog Prioritization was jointly designed in an online conversation between Martin Burns, Don Reinertsen, Chris Matts, Joshua Arnold, Tony Grout, and Troy Magennis. It is maintained by Focused Objective and used with permission.

Keep learning

Read more articles about: App Dev & TestingAgile