WSJF: Weighted Shortest Job First Prioritization Explained

By Tara Minh · Updated Oct 12, 2026

WSJF (Weighted Shortest Job First) is a prioritization model that ranks work by dividing its cost of delay by its job size. Items that lose the most value from waiting, and take the least effort to finish, go first. Teams score each factor relatively, then sort by the result.

Key Facts

• The SAFe framework describes WSJF as the relative cost of delay divided by the relative job duration.
• Cost of delay in SAFe is built from relative user and business value, time criticality, and risk reduction and/or opportunity enablement.
• The SAFe page opens with a line attributed to Don Reinertsen's The Principles of Product Development Flow: "If you only quantify one thing, quantify the Cost of Delay."
• SAFe notes that WSJF ignores sunk costs, which it presents as a basic principle of Lean economics.
• Black Swan Farming defines cost of delay as a way of communicating the impact of time on the outcomes we hope to achieve.

What is WSJF?

Most prioritization methods ask "what's the most valuable thing we could build?" WSJF asks a sharper question: "what's the most valuable thing we could build first, given that everything else has to wait?" Waiting has a price, and different jobs have very different prices.

Picture two projects. One is a compliance report with a regulator's deadline in six weeks. The other is a nicer-looking dashboard with no date attached. If both take about the same effort, delaying the compliance report is far more expensive. WSJF puts that intuition into a number so a group can see it, debate it, and agree on it.

The idea traces back to Don Reinertsen's work on product development economics. His book The Principles of Product Development Flow is the source SAFe cites for the cost of delay quote above. SAFe then packaged the thinking into a scoring model that large agile programs can run every planning cycle.

The WSJF formula

WSJF = Cost of Delay / Job Size

SAFe's own wording is "relative cost of delay divided by relative job duration." In practice, most teams put job size (or a proxy for duration) in the denominator, because the true duration is unknowable until the work is done. Size is a stand-in for how long the work will block the next item in the queue.

The numerator, cost of delay, is the sum of three parts:

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement

Each part gets its own relative score. Here's what each one asks.

User-business value

How much do customers or the business want this? Think revenue, retention, satisfaction, or a penalty avoided if it ships. The higher the pull, the higher the score.

Time criticality

How fast does the value decay? A feature tied to a fixed date, a seasonal window, or a competitor's launch scores high. A feature that's just as valuable next quarter as today scores low. This is the factor most other scoring models leave out, and it's what makes WSJF a sequencing tool rather than a plain ranking tool.

Risk reduction and opportunity enablement

Does finishing this remove a risk (a security gap, a fragile system, a compliance exposure) or unlock future options (a platform piece other teams are waiting for)? Work that makes later work possible or safer earns points here, even if customers never see it.

Job size

How big is the job, relative to the others on your list? This is the cost side. A small job that delivers the same cost of delay as a big one should go first, because it clears the queue sooner and frees capacity for the next item. That's the "shortest job first" half of the name.

Why relative scoring?

WSJF doesn't ask for dollars or hours. It asks for comparisons. You take the smallest or least urgent item in a category, call it a low number, and score everything else against it. A common choice is a modified Fibonacci scale such as 1, 2, 3, 5, 8, 13, 20, because the widening gaps stop people from arguing about the difference between a 7 and an 8. If your team already sizes work with story points or T-shirt sizing, reuse that sizing for the job size column instead of inventing a second scale.

Two rules keep relative scoring honest:

• Score one column at a time across all items, not one item at a time across all columns. Comparing items against each other in the same column is what makes the numbers meaningful.
• Anchor each column with a reference item, so "5" means the same thing at the start of the meeting and at the end.

WSJF worked example

The numbers below are invented for illustration. They aren't benchmarks. A small product team has five candidate items for next quarter and scores them on a 1, 2, 3, 5, 8, 13, 20 scale.

Check item A: 8 + 13 + 3 = 24. Divide by a job size of 5 and you get 4.8.

Read the result in order of WSJF: A, B, C, D, E. A few things stand out.

The checkout bug wins despite lower raw cost of delay than the compliance report, because it's a smaller job. The compliance report has the biggest cost of delay in the list (33), but its size of 8 pulls it to second. If its deadline is fixed and real, you'd probably start it right away anyway, and that's a legitimate override. Use the score to start the conversation, not end it.

The dashboard redesign has the highest user-business value (13) and still lands last. It's big, it isn't urgent, and it doesn't unlock anything. That doesn't mean it's a bad idea. It means it's the one to do when capacity opens up, or to break into smaller slices that score better on their own.

SSO sits in the middle because most of its score comes from opportunity enablement. If three other teams are blocked on it, argue for a higher score. That's a good use of the discussion.

WSJF scoring template

Copy this table into a spreadsheet. The sample row is illustrative.

If the three score columns are D, E and F, and job size is H, the spreadsheet formulas are =D2+E2+F2 for cost of delay and =G2/H2 for WSJF (with cost of delay in column G). Add a dropdown limited to your scale values so no one types a 6 or a 10.

How to use WSJF step by step

1. List the candidates. Pull items from your product backlog, keeping each one similar in scope. A giant epic next to a tiny fix distorts the comparison, so split epics first.
2. Pick the scoring group. Include the people who understand value (product, business owners), urgency (sales, support, compliance) and effort (the delivering team).
3. Choose a scale and write it down. Modified Fibonacci works well. Agree on what the low end means.
4. Find the anchors. In each column, pick the item with the smallest score and set it to 1 or 2. Everything else is "how many times bigger or more important than that?"
5. Score user-business value. Go through the whole list for this column only.
6. Score time criticality. Ask what happens if this slips a month, and whether the answer is "nothing" or "we lose the window."
7. Score risk reduction and opportunity enablement. Ask what breaks or stays blocked if this doesn't happen.
8. Score job size. Let the people who'll do the work give the number.
9. Add and divide. Sum the three value columns, divide by size, sort descending.
10. Sanity-check and decide. Look at the top five and bottom five. Fix any input that feels wrong, not the formula, then commit to an order.
11. Re-score regularly. Time criticality changes fast. Re-run the numbers during backlog refinement or before each planning cycle. SAFe's framing is that priorities should be updated continuously in flow-based systems.

WSJF vs other prioritization frameworks

The simplest way to choose: if the main question is "what do users gain?", RICE fits. If the main question is "what costs us most to postpone?", WSJF fits. They also combine well. Use MoSCoW to define what's in a release, then use WSJF to order the items inside it.

WSJF examples by business function

WSJF was built for software programs, but the logic works anywhere work competes for the same capacity. The numbers below are illustrative.

Product and engineering. A payments team scores a security patch (value 5, time criticality 13, risk reduction 20, size 3) at 12.7, ahead of a new report builder (value 13, time 3, risk 2, size 13) at 1.4. Risk reduction is what carries the patch.

Marketing. A campaign page tied to a trade show in two weeks scores high on time criticality (20) even if its value is moderate. A brand refresh with no date scores low on urgency. WSJF makes it easy to explain why the show page gets built first.

Sales operations. Fixing lead routing before a quarter-end push has a clear decay window. Cleaning up legacy CRM fields has value but no date. The routing fix goes first, and the cleanup waits for a quiet week.

HR. Updating onboarding paperwork for a policy that takes effect on a fixed date scores high on time criticality and risk reduction. A manager training refresh scores high on value but low on urgency.

IT. Renewing a certificate or retiring an unsupported system carries risk reduction that's invisible until it fails. Scoring that column explicitly stops quiet-but-dangerous work from losing every vote to flashy requests. At scale, this pairs with PI planning, where teams in a SAFe program agree on the next increment's work together.

WSJF dos and don'ts

Do:

• Score each column across the whole list before moving to the next column.
• Use the same scale and reference items for every item in a round.
• Let the people doing the work set job size.
• Argue about the scores. The disagreements show where people hold different assumptions.
• Revisit time criticality often, because it's the score that changes fastest.
• Split large items into smaller slices so job size doesn't swamp everything else.

Don't:

• Don't use sunk cost as a reason to score something higher. SAFe's page is explicit that WSJF ignores sunk costs.
• Don't tweak numbers until your favorite item wins. If something must go first, say so openly.
• Don't treat a 3.25 and a 3.4 as a real difference. Scores are rough.
• Don't mix dollar estimates into some rows and relative points into others.
• Don't let small size alone drive the ranking. A cheap, low-cost-of-delay item can crowd out an important big one, so look at the top of the list with judgment.
• Don't ignore hard dependencies. If B can't start until A finishes, sequence them accordingly.

Limitations of WSJF

WSJF compresses a lot of judgment into one number, and the number can look more exact than it is. Each score is a group opinion, so an anchoring bias (the first loud estimate sets everyone's) is a real risk. Calling on people to score independently first, then compare, helps.

The model also treats cost of delay as a simple sum of three parts. In reality, the parts can interact: a deadline can turn a modest-value item into an urgent one. That's why the score should open a discussion rather than close it.

Finally, job size is a proxy. If two items score close to each other and one has far more uncertainty in its size, slice the uncertain one or run a small spike first.

Putting WSJF to work

Take the ten items sitting at the top of your backlog and block 60 minutes. Score one column at a time, divide, and look at what moved. The usual surprise is a small, unglamorous item that jumps to the top, and a large favorite that drops. Whether you follow the order exactly or override it, you'll have a written reason for what comes first, and that's what makes the next planning conversation shorter.

Related reading

• RICE Prioritization
• MoSCoW Method
• Scaled Agile Framework (SAFe)
• PI Planning
• Product Backlog
• Story Points
• T-Shirt Sizing
• Backlog Refinement
• User Story Mapping
• Shape Up Method