Why you shouldn’t use WSJF to prioritise your backlog

Probably due to the rising popularity of SAFe, Weighted Shortest Job First (WSJF) has become quite well known in recent times as a way to prioritise work based both on the value it will deliver and how long it will take to do. For those of you not familiar with it, Steve McConnell gives a nice, short overview of it in his excellent book More Effective Agile. There is also a nice summary available on the SAFe website. In simple terms, it works like this:

• Estimate the value that each work-item will deliver
• Estimate how long it will take to deliver each work-item
• In each case, divide the value by the duration
• Start work-items first which have the highest result from this calculation

Now, before I talk about the pitfalls and reasons to be very careful about using WSJF, first let me say this: in my view, it is extremely helpful as a way of getting people out of the habit of delivering lots of stuff in parallel (the worst possible approach when it comes to delivering value). And it also forces people to go beyond the idea of simply prioritising the most valuable items, because it makes you realise that how soon you get that value makes a difference.

However, WSJF relies on some important assumptions:

That the cost of delay is linear

The cost of delay is the opportunity cost of not having a new feature available (i.e. how much you are out-of-pocket compared to if the feature was completed). For WSJF prioritisation to be correct, the cost of delay for all work items must be linear. For example, for every day that you don’t have a given feature, you will be ￡1,000 worse off.

Many real-world features don’t have a linear cost of delay. If you face a harsh regulatory penalty if something is not completed by a certain date, then any day before this deadline has zero cost of delay, whilst delivering after it will have a significant cost of delay. If you need a certain feature in order to retain customers who are switching to a competitor’s product, then the cost of delay now will be much higher than it will be in a few months’ time (after many of them have already left you). The simple WSJF calculation doesn’t take into account cases where the cost of delay varies over time.

There are no value dependencies

Most of us are used to thinking about technical dependencies (feature B can’t be started until feature A has been completed). But there is almost always a value dependency between features as well. Rarely is the total value of delivering feature A and feature B the sum of the value of delivering either of them individually. Sometimes there is multiplier effect: having one or the other is acceptable, but having both elevates your product to a whole new level. Sometimes they counteract each other: having at least one is a “must have”. But once you have one, the other one becomes a “nice-to-have”. WSJF does not take into account these kinds of value dependencies.

You are using task duration

With WSJF you have to use the expected task duration, not the expected effort (or other proxy for effort like story-points). This should be clear, after all the “S” in WSJF refers to the shortest task rather than the smallest. However, often teams will use task size as a proxy for duration. Unfortunately, task size often makes a pretty terrible proxy, as it doesn’t take into account:

• Fluctuations in team size
• The fact that many tasks can’t be completed faster by having more people working on them (in other words, dedicating 10 people to a single task usually won’t get it done 10 times faster)
• Dependencies between tasks (including cases where one task could be completed a lot faster if it is done after another one).
• Batch steps in your process that introduce delays completely unrelated to the size of specific tasks

This last point deserves a little bit more attention. If you have big batch steps, either in signing-off requirements or for release into production, using WSJF for the parts in-between is virtually pointless. All the value will be delivered (or not) at the same time anyway. The order you do things in will not change this, and you would be far better off optimising the sequence based on other factors, such as early reduction of risk, availability of people and technical dependencies. You would also, in my view, be far better off focussing on how you can reduce your large batch sizes before trying to use WSJF to prioritise the work in-between them.

So, if WSJF is quite problematic in practice, what would I suggest instead?

In my book Better Agile: How every software team can spend less time firefighting and have more fun building great software I describe how teams can take a simplified, pragmatic approach to prioritisation, based around:

• Not trying to have the whole backlog prioritised all of the time, but instead doing just enough prioritisation so the team knows what they need to work on next
• Quickly identifying the “obvious” high priority work-items
• If necessary, focusing effort on the boundary cases (between the obvious high priority and obvious low priority)

However, I also explain that having a sufficiently prioritised backlog is only one of the things you need to have in place to get the right people doing the right things. Backlog prioritisation is only useful if it covers all the work being directed towards the team (which is often more than only features in a product roadmap). Backlog prioritisation is also not useful if the team are not allowed to focus on delivering the high priority items (without constant interruptions and diversions). But, if you do capture all work in your backlog, prioritise it sufficiently, and then allow the team to focus just on the highest priority items, then you will be outperforming many teams in terms of your ability to deliver the maximum value, as quickly as possible.

Photo by Joshua Golde on Unsplash