WSJF Formula Explained: Weighted Shortest Job First Example

The WSJF formula is cost of delay divided by job size. Cost of delay is user and business value plus time criticality plus risk reduction or opportunity enablement, each scored on a modified Fibonacci scale, and the job with the highest score goes first. In the worked example below, a compliance fix scoring (5 + 20 + 3) / 5 = 5.6 outranks a dashboard redesign scoring (8 + 3 + 2) / 8 = 1.6.

In short. Weighted shortest job first (WSJF) sequences work by value lost per unit of effort spent waiting, so a deadline-driven job can beat a flashier one. The formula comes from Don Reinertsen's cost of delay economics in The Principles of Product Development Flow (2009) and was built into the Scaled Agile Framework. It fails when teams inflate time criticality or shrink job size to get the ranking they already wanted.

Every prioritization framework claims to be objective, and most of them just move the argument one layer down: instead of fighting about which feature ships first, the team fights about which feature is "high priority." WSJF forces the argument to happen over specific numbers instead of adjectives, which is a smaller improvement than it sounds like and a real one anyway.

What Weighted Shortest Job First Actually Calculates

WSJF ranks a backlog of candidate jobs, not tasks inside a plan already underway. Each job gets four scores on a modified Fibonacci scale of 1, 2, 3, 5, 8, 13, 20:

Input	What it measures	Example driver
User and business value	Revenue, satisfaction, or strategic importance to the user or the business	A feature blocking a top account's renewal scores high
Time criticality	How fast the value decays if the job waits	A compliance deadline scores high; a nice-to-have doesn't
Risk reduction / opportunity enablement	Value that isn't direct revenue but unblocks future work or removes a known risk	A spike that de-risks a bigger bet later
Job size	Relative effort or duration to deliver	Story points, ideal days, or any consistent relative unit

Cost of delay is the first three added together. WSJF divides that sum by job size. Don Reinertsen's cost of delay economics, later formalized into the Scaled Agile Framework (see SAFe explained for PMOs), put it plainly: if a team quantifies only one thing about a piece of work, quantify what it costs to make that work wait.

Walking One Scoring Session End to End

Say a team is comparing four candidate jobs for next quarter. Job A is a dashboard redesign: business value 8, time criticality 3, risk reduction 2, job size 8. Cost of delay is 8 + 3 + 2 = 13, and WSJF is 13 / 8, or about 1.6. Job B is a compliance fix with a hard regulatory date: business value 5, time criticality 20, risk reduction 3, job size 5. Cost of delay is 28, and WSJF is 28 / 5, or 5.6. Job C is a small internal tooling improvement: business value 3, time criticality 1, risk reduction 1, job size 2. Cost of delay is 5, and WSJF is 2.5. Job D is an onboarding fix: business value 5, time criticality 5, risk reduction 2, job size 3. Cost of delay is 12, and WSJF is 4.0.

Rank	Job	Cost of delay	Job size	WSJF
1	B: Compliance fix	5 + 20 + 3 = 28	5	5.6
2	D: Onboarding fix	5 + 5 + 2 = 12	3	4.0
3	C: Internal tooling	3 + 1 + 1 = 5	2	2.5
4	A: Dashboard redesign	8 + 3 + 2 = 13	8	1.6

The compliance fix wins clearly, not because someone declared it urgent, but because its time criticality score alone outweighs the entire cost of delay of every other job. That's the useful property: WSJF surfaces the deadline-driven job even when its raw business value is lower than the flashier dashboard project.

The diagram below plots the jobs to show why job size, the denominator, matters as much as cost of delay, the numerator.

The Two Inputs Teams Routinely Fudge

Time criticality is the easiest score to argue for without evidence, because urgency feels self-justifying in the room: "this is time-sensitive" is a sentence nobody wants to push back on in a planning meeting, even when the actual cost of a two-sprint delay is close to zero. The fix is procedural: require a stated reason for any time criticality score above the median, a real deadline, a contract clause, a customer commitment, not a feeling.

Job size is the more damaging fudge because it's a division, not an addition: shrinking the denominator inflates the whole score. A team that wants job X to win learns fast that scoring it as a 3 instead of an honest 8 does more for its ranking than inflating any single cost of delay input. Estimation review has to happen for job size the same way it happens for story points in sprint planning; a size score nobody can defend against a comparable historical job is a size score that shouldn't be trusted.

When WSJF Fits and When It Doesn't

WSJF assumes the jobs being compared are roughly comparable in kind, features competing against features, epics against epics. Comparing a two-day bug fix against a six-month platform migration on the same WSJF scale produces numbers that are mathematically valid and practically useless, because the size gap swamps everything else in the formula. WSJF also isn't a replacement for a scope conversation: it tells you the order to work in, not whether the backlog is too large for the team's actual capacity, which is the harder problem MoSCoW prioritization runs into once too many items get called a Must have.

WSJF ranks a backlog. It doesn't build the plan. Once a job wins its slot, it still needs the same task breakdown, dependencies, and dates any other committed work needs, the mechanics portfolio and priority fights usually come back to once the ranking argument is settled and the harder scheduling argument starts.

Making the Ranking Stick

A WSJF score only holds up if it survives someone asking "why is time criticality a 13 and not a 5" in front of the group that will live with the ranking. Score jobs together, in the same session, so the relative scale stays consistent across the whole backlog rather than drifting between people scoring in isolation. Portfolio triage covers the harder version of this problem, ranking not features but entire projects, where the same fudging risk shows up at a much higher cost per mistake. WSJF earns the argument over adjectives. It doesn't survive an argument over which adjective the numbers were secretly standing in for.

More prioritization mechanics like this live on the Onplana blog, including the project-priority fights WSJF is usually brought in to settle.

Frequently asked questions

What is weighted shortest job first (WSJF)?

WSJF is a prioritization formula that scores each candidate job as its cost of delay divided by its job size, so the jobs that lose the most value by waiting, relative to how long they take, get sequenced first.

What is the WSJF formula?

WSJF equals cost of delay divided by job size. Cost of delay is the sum of three components: user and business value, time criticality, and risk reduction or opportunity enablement.

What scale do you use to score WSJF inputs?

A modified Fibonacci sequence, typically 1, 2, 3, 5, 8, 13, 20. The gaps widen at higher numbers on purpose, so a team can't hide a weak argument for a high score inside a false sense of precision.

Who created the cost of delay concept behind WSJF?

Don Reinertsen described cost of delay economics in The Principles of Product Development Flow, arguing that if a team quantifies only one thing about a piece of work, it should be this. Dean Leffingwell later built WSJF into the Scaled Agile Framework.

What are the two WSJF inputs teams most often fudge?

Time criticality and job size. Time criticality gets inflated because urgency is the easiest score to argue for without evidence, and job size gets underestimated because a smaller denominator produces a higher, more flattering WSJF score for the same job.

Does WSJF replace a Gantt-based schedule?

No. WSJF orders a backlog of candidate jobs before they're committed to a plan. Once a job is selected, it still needs real task breakdown, dependencies, and dates, the things a Gantt schedule tracks.