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.
Key takeaways
- WSJF stands for weighted shortest job first. The formula is Cost of Delay / Job Size, and the highest scores are sequenced first.
- Cost of delay is the sum of three relative scores: business value, time criticality, and risk reduction or opportunity enablement.
- Each input is scored on a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20) so estimates stay relative and comparable.
- WSJF's strength over RICE is that it captures urgency. Its weakness is that the cost-of-delay inputs are subjective and easy to inflate.
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.
| Component | Question it answers |
|---|---|
| User or business value | How much do users or the business want this, and what is the revenue or cost impact? |
| Time criticality | How fast does the value decay? Is there a deadline, a market window, or a customer we lose by waiting? |
| Risk reduction or opportunity enablement | Does this reduce future risk or unlock other work, even if its direct value is modest? |
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.
| Item | Business value | Time criticality | Risk or opportunity | Cost of delay | Job size | WSJF |
|---|---|---|---|---|---|---|
| Compliance update | 5 | 13 | 8 | 26 | 3 | 8.7 |
| New reporting feature | 13 | 3 | 2 | 18 | 8 | 2.3 |
| Platform refactor | 3 | 2 | 13 | 18 | 13 | 1.4 |
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.