Skip to content
← All terms

Glossary

What is WSJF (weighted shortest job first)?

Weighted shortest job first: a sequencing rule that divides each job's cost of delay by its size or duration and does the highest ratio first, so the work that is most expensive to keep waiting per unit of effort goes ahead.

The idea comes from Don Reinertsen's work on product development flow, where it is a queueing rule: when jobs differ in both urgency and length, ordering them by cost of delay divided by duration minimises the total cost of waiting. The insight that survives every implementation is that a short job with a moderate cost of delay can rightly go ahead of a long one with a high cost of delay.

How SAFe calculates WSJF

The Scaled Agile Framework made WSJF its standard way to order a backlog, and replaced money with relative estimates. Cost of delay becomes the sum of three components: user and business value, time criticality, and risk reduction or opportunity enablement. Each is scored on a modified Fibonacci scale — 1, 2, 3, 5, 8, 13, 20 — relative to the other jobs, one column at a time, with the smallest in each column set to 1. Job size is scored the same way and stands in for duration.

An example. Job A scores 8 for value, 5 for time criticality and 2 for risk reduction: a cost of delay of 15. Its size is 5, so its WSJF is 3. Job B scores 5, 3 and 1 — a cost of delay of 9 — with a size of 2, giving 4.5. B goes first although A is worth more, because B holds A up for less time than A would hold up B.

WSJF vs RICE

Both divide value by effort; they differ in what counts as value. RICE asks how many people a change reaches and how much it moves them, which suits product bets. WSJF asks what waiting costs, which makes time explicit: a regulatory deadline scores high on time criticality with no user-facing value at all. The SAFe version is also purely relative — its numbers mean nothing outside the set of jobs scored together — where RICE at least tries to anchor reach to a real count.

When it fits, and when it does not

It fits a flow of comparable jobs competing for the same delivery capacity, re-scored regularly, where the question really is what to do next. It fits best when cost of delay can be stated in money per week, as Reinertsen intended; the relative version is easier to run and much easier to argue into whatever order the room already preferred.

It does not fit as a commitment decision. Job size is a proxy for duration, and the proxy breaks when a small job waits three weeks on another team or a large one can be done in parallel. Summing three relative scores is arithmetic on rankings. And the ratio says nothing about whether a job is understood well enough to size, or whether the team it lands on has room. WSJF sequences work that is ready; it cannot tell you which work is ready.

Related terms

  • Commitment exception — A recorded justification required to commit to work that is not yet decision-ready, naming why it is early, what is still unknown, who accepts the risk, and what condition would change the decision.
  • Delivery governance — The practice of deciding what to commit to — establishing value, ownership, capacity, dependencies and open questions before people, budget or a date are promised.
  • Decision-ready demand — A demand that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.

This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.