Weighted Shortest Job First: The Two Inputs Teams Fudge
Weighted shortest job first ranks work by cost of delay divided by job size, and the score only holds up when two of its inputs aren't quietly inflated.
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." Weighted shortest job first doesn't remove the argument. It 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.
The direct answer: weighted shortest job first (WSJF) scores each candidate job as its cost of delay divided by its job size, so a team sequences work by how much value is lost per unit of effort spent waiting, not by who argued loudest in the planning meeting. Cost of delay itself is three numbers added together: user and business value, time criticality, and risk reduction or opportunity enablement. The formula is simple. What breaks it is teams fudging job size or time criticality to get the ranking they already wanted.
WSJF equals cost of delay (business value plus time criticality plus risk reduction or opportunity enablement) divided by job size. Score every input on a modified Fibonacci scale, 1, 2, 3, 5, 8, 13, 20, so a weak argument for a high score can't hide behind false precision. The formula survives contact with executives because it makes the tradeoff explicit: a job with a huge audience but no urgency scores differently than a job with a small audience and a hard deadline, and the difference is visible in the math instead of buried in someone's opinion. It fails when time criticality gets inflated to manufacture urgency, or job size gets shrunk to manufacture a better ratio; both moves are common enough that a serious WSJF session checks for them before trusting the ranking.
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, 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 three 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.
The compliance fix wins clearly, not because someone declared it urgent, but because its time criticality score alone outweighs the other two jobs' entire cost of delay. 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 same three 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.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.