WSJF Weighted Shortest Job First Formula and Example

WSJF, weighted shortest job first, is a prioritization method from the Scaled Agile Framework that sequences work by economic urgency. You divide each item's cost of delay by its job size, and the items with the highest result go first. The logic is that short jobs that lose the most value by waiting deliver the best return on the time you spend, so doing them first maximizes value across the whole backlog.

What is WSJF (weighted shortest job first)?

WSJF is a method for ordering a backlog of features, capabilities, or epics so the work with the best economic payoff per unit of time is done first. It comes from SAFe, where portfolios and agile release trains have to sequence work across many teams and cannot fund everything at once. Rather than ranking by value alone or size alone, WSJF combines both: it favors work that is both valuable to delay-sensitive and quick to finish.

The name captures the idea directly. Among jobs of similar value, do the shortest first, because finishing it frees capacity sooner and starts returning value while longer jobs are still in flight. Weighting by cost of delay adds the value side, so a long job with enormous delay cost can still outrank a quick job that nobody is waiting on.

What is the WSJF formula?

The WSJF formula is Cost of Delay divided by Job Size. Cost of delay is what you lose by not having the work now; job size is how long or how much effort it takes. Dividing one by the other gives value per unit of duration, and sorting the backlog by that number highest-first gives the sequence.

WSJF = Cost of Delay / Job Size, where Cost of Delay = Business Value + Time Criticality + Risk Reduction or Opportunity Enablement.

Because the inputs are relative scores rather than dollars, WSJF produces a relative ranking, not a financial figure. That is deliberate. SAFe assumes you often cannot put a reliable dollar value on delay, so it uses comparative scores that a team can agree on quickly and still get the sequence right.

How do you score cost of delay?

Cost of delay in WSJF is the sum of three components, each scored relative to the other items in the same batch. Score one column at a time across all items, not one item at a time down all columns, so your scale stays consistent.

Swipe to see more →

Time criticality is the component that sets WSJF apart from value-only models. It is where a regulatory date, a competitor's move, or a seasonal window enters the math, which is why WSJF ranks deadline-driven work correctly where a model with no time term would underrate it.

How do you calculate WSJF? A worked example

Score each component on a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20), sum the three for cost of delay, then divide by job size scored on the same scale. The item with the highest result is sequenced first.

Swipe to see more →

The compliance update wins despite modest business value, because its high time criticality and small job size give it the best cost of delay per unit of work (26 / 3 = 8.7). The reporting feature has the highest raw value but a bigger job size drags its WSJF down. This is the whole point of the method: it sequences by urgency-weighted return, not by value or size alone.

Why do you divide by job size?

You divide by job size because time is the constraint, not just value. Two jobs with the same cost of delay are not equal if one takes a week and the other takes a quarter; finishing the short one first returns its value sooner and releases the team to start the next job. Dividing by size rewards that, so a stream of small high-value jobs beats one giant job that blocks everything behind it.

This is also why WSJF discourages gold-plating. Growing a job's scope raises its size, which lowers its WSJF, so the model naturally pushes teams toward the smallest slice that delivers the value. If you cannot estimate job size well, WSJF loses reliability, which is why relative sizing on the Fibonacci scale matters as much as scoring the value side.

What is a good WSJF score?

There is no absolute good WSJF score, because the inputs are relative and the number only means something next to the other items scored in the same batch. A WSJF of 8 is only high if the rest of the backlog scores lower. Re-score the batch whenever new work arrives or estimates change, and read the ranking rather than the raw figures.

The failure mode to watch is inflation of the cost-of-delay inputs. Because business value, time criticality, and risk are subjective scores, a team that wants its item moved up can quietly rate its own time criticality high. Guard against it by scoring one component across all items at once and having a neutral facilitator, usually from the portfolio or agile PMO, hold the scale steady.

Where is WSJF used?

WSJF is the standard prioritization method for SAFe, used to sequence epics in the portfolio backlog and features in program backlogs across agile release trains. It fits environments where many teams draw from a shared queue and sequencing across them is the hard part, which is exactly the problem lean portfolio management is built to solve. Outside SAFe, plenty of agile teams borrow WSJF for any backlog where deadlines and value both matter.

It fits less well when you have solid dollar estimates and want the honest economic number, in which case raw cost of delay or a financial model beats a relative proxy. For where WSJF sits in the larger picture, see lean portfolio management, the project scoring model comparing it with RICE and weighted scoring, and the prioritization frameworks guide. For the economics its numerator is built on, read cost of delay, and for the full portfolio process, how to prioritize a project portfolio.

The job size mistake that quietly breaks the ranking

SAFe says job size. Almost every team substitutes story points, and those are not the same thing. Story points measure effort. WSJF's denominator is meant to represent how long the item occupies the constraint, and effort only equals duration when the team doing the work is the only thing standing between the item and done.

At team level the substitution is usually harmless. At portfolio level it is not, because portfolio items queue behind shared people, a single architect, a security review, a vendor, or an environment. An epic that is eight points of effort but waits three weeks for one scarce reviewer has a real job size far above eight, and WSJF will rank it too high every time.

Swipe to see more →

If you are running WSJF above team level and your denominator is story points, switch it to calendar duration and re-rank. The order will change, and the new order will be the more honest one. Identifying which resource is actually the constraint is the same exercise as resolving resource contention.

WSJF has no dependency term, and that is its biggest practical gap

The formula contains value, urgency, risk, and size. It contains nothing about what an item depends on. So WSJF will cheerfully put a high scoring feature at the top of the list when the enabler that unblocks it sits at position 30 with a low score, because enablers usually have modest direct business value and large job sizes.

The fix is not to bolt a dependency factor into the formula, which makes the scores uninterpretable. Treat WSJF as producing a preference order, then run a separate constraint pass over it:

1. Rank the batch by WSJF as normal and leave the scores untouched.
2. Map the hard dependencies between the top twenty items only. Below that the ordering is noise anyway.
3. Wherever an item's blocker sits lower in the list, pull the blocker up to just above it. Record that you moved it and why.
4. Recheck capacity: pulling enablers forward usually front loads work onto exactly the scarce skills that made them enablers.

Keeping the promotion log matters, because six weeks later somebody will ask why a low scoring item is being worked on. The answer, that it unblocks three higher scoring items, is a good one, but only if you wrote it down. A dependency matrix is the usual place to hold the mapping in step two.

Sequencing is not scheduling

WSJF answers one question: in what order should we take this work. It does not tell you when anything starts, whether you have the people, or what fits in the next quarter. A WSJF ordered list read as a plan is the most common way the method gets discredited, because the list implies commitments nobody made.

Run the order through capacity before it becomes a plan. Take the ranked list, walk down it drawing against available capacity per skill, and stop at the line where capacity runs out. Everything above that line is the plan. Everything below it is the backlog, and saying so plainly is what stops the ranking from being read as a promise. The mechanics of drawing down against real availability are covered in resource and capacity planning.

How to stop cost of delay scores from inflating

Every relative scoring model degrades the same way. The people who want their work prioritized are the people supplying the scores, and time criticality is the easiest of the three components to inflate because it sounds like a fact and is actually an opinion.

The control that works is cheap and specific. For any item scored 13 or 20 on time criticality, require two things written on the item: a named date, and what measurably happens on that date. Not "the market is moving" or "leadership is asking." A regulatory deadline, a contract expiry, a competitor launch already announced, a seasonal peak. Items that cannot supply both get re-scored down to 5 on the spot.

Swipe to see more →

Run the date test once and it changes behavior permanently, because people stop submitting urgency claims they know will be checked. Holding that line is a facilitation job, which is why it belongs with whoever runs the prioritization workshop rather than with the people submitting items.

Why the modified Fibonacci scale instead of one to ten

The scale is 1, 2, 3, 5, 8, 13, 20 because the gaps widen as the numbers grow, which forces a decision. On a linear one to ten scale, most items cluster between 5 and 7 and the ranking flattens into noise. The Fibonacci gaps make people choose whether something is a 5 or an 8, and there is no comfortable middle to hide in.

It also reflects how estimation accuracy actually behaves. You can tell a 1 from a 2 with confidence. You cannot tell a 16 from a 17, so the scale stops offering the choice. Use the same scale for all four inputs so the arithmetic stays comparable.

Six ways WSJF goes wrong in practice

Swipe to see more →

When to use something other than WSJF

WSJF earns its place when you have many items, a shared queue, real deadlines, and no reliable dollar figures. Change any of those and a different model fits better.

Swipe to see more →

Frequently asked questions

Does WSJF account for dependencies?

No. The WSJF formula contains business value, time criticality, risk reduction, and job size, and nothing that represents what an item depends on. Enablers that unblock high scoring work tend to rank low, because they have modest direct value and large job sizes. Handle it with a separate constraint pass after ranking: map dependencies across the top items and promote blockers above the items they block, recording each promotion.

Can you use WSJF outside SAFe?

Yes. WSJF is just cost of delay divided by job size, and nothing in that requires agile release trains or the rest of the SAFe apparatus. Teams use it for any backlog where both deadlines and value matter. What it does require is a batch of items large enough for relative scoring to mean something, roughly eight or more, and a facilitator who will hold the scale steady across everyone submitting work.

How often should you recalculate WSJF?

Re-score the whole batch whenever you next plan, typically each quarter or each planning increment, and immediately if a large new item arrives or a deadline changes. Do not update single items in isolation, because WSJF scores are only comparable within one scoring session. A number carried forward from a previous batch cannot be reliably compared with a number produced in the current one.

What is the difference between WSJF and cost of delay?

Cost of delay is the economic loss from not having something now, and in WSJF it is the numerator, built from three relative scores rather than measured in currency. WSJF then divides that by job size to get value per unit of time. So cost of delay tells you what waiting costs, while WSJF tells you what order to work in given that everything takes time and capacity is finite.

What is a job size in WSJF?

Job size represents how long the item will occupy your delivery capacity, scored on the same modified Fibonacci scale as the other inputs. Most teams substitute story points, which measures effort rather than elapsed time. Above team level that substitution distorts the ranking, because portfolio items spend most of their life waiting on shared people rather than being worked on, so calendar duration is the better denominator.

Where this fits in portfolio prioritization

Swipe to see more →