“WSJF (Weighted Shortest Job First): Formula and Examples”

What is WSJF?

Weighted Shortest Job First is a prioritization model that sequences work by economic value per unit of duration. It comes from Don Reinertsen’s *Principles of Product Development Flow*, which argues that in a flow-based system the sequence of jobs matters more than a theoretical return on investment calculated for each job in isolation.

The name describes the mechanic: in a queue, doing the shortest high-value job first reduces the total value left waiting, and weighting by cost of delay stops the model degenerating into “do the quickest thing”.

SAFe adopted WSJF as its standard prioritization method for program-level backlogs, scored at PI boundaries. SAFe’s guidance is explicit that WSJF supports judgment rather than replacing it, and that it is not the sole determinant for portfolio-level decisions.

A useful property falls out of the formula: WSJF only looks at work that remains. Sunk costs disappear from the calculation automatically, which is exactly what you want when deciding what to do next.

What is the WSJF formula?

The formula is a single division:

WSJF = Cost of Delay ÷ Job Size

And in the SAFe formulation, Cost of Delay is a sum of three separately scored components:

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

Two clarifications prevent most of the confusion around WSJF.

Job size is a proxy for duration, not an effort score. A job can be small in effort and long in duration because it waits on a supplier or an approval. When that happens, adjust the size upward, because the model cares about how long value is delayed.

The three cost-of-delay components are scored independently. If you score them as one blended “importance” number, you lose the ability to see why an item ranks where it does. A feature with low user value and extreme time criticality should look different from one with high user value and no deadline pressure, even if the sums are equal.

How do you score a backlog with WSJF?

You score one column at a time across all items, not one item at a time across all columns. That single procedural choice determines whether the result means anything.

Step 1: Choose the candidate set. Ten to twenty items, refined enough to compare. More than twenty and the session becomes a debate about wording rather than value.

Step 2: Get the right people in the room. Product management and business owners for value and criticality, an architect for risk, and team representatives for size. One person scoring everything produces a ranking that reflects one person’s model of the business.

Step 3: Score user-business value. Find the least valuable item and give it a 1. Score everything else relative to it using 1, 2, 3, 5, 8, 13, 20. Do not start from the most valuable item, because anchoring at the top inflates everything.

Step 4: Score time criticality, then risk reduction. Same method, separate columns. Give each column its own 1.

Step 5: Add the three columns. The sum is the cost of delay. It is a relative number with no units, and that is intentional.

Step 6: Score job size with the delivery team. Smallest job gets a 1. The team scores this, not product management — the people doing the work know how big it is.

Step 7: Divide, sort, and sanity-check. Cost of delay divided by size, highest first. Then read the ranking out loud. If the order looks obviously wrong to the room, a score is wrong, and finding it is more valuable than defending the spreadsheet.

> Practical tip: Every column must contain at least one 1. Without an anchor, scores drift upward until everything sits at 13 or 20 and the ratio stops discriminating.

Worked example: ranking five features

Here is a realistic program backlog scored by a product owner, a business owner, an architect, and two tech leads in a 75-minute session.

Three things in that table are worth reading carefully.

The highest cost of delay did not rank first. The audit log has a cost of delay of 38 — the highest in the set — but a size of 8 pushes it to third. This is the central tension of WSJF, and the correct response is not to override the formula reflexively. If the regulator’s date is genuinely fixed, the audit log is a constraint, not a candidate: constraints get scheduled first and WSJF ranks what remains. If the date is soft, the ranking is telling you something useful about how expensive the delay actually is.

The lowest-value item nearly beat a high-value one. Self-service reporting has the highest user-business value in the set (13) but ranks fourth, because its value does not decay and its size is large. Mobile redesign, with identical value, lands last because it is bigger still.

The winner is unglamorous. A checkout performance fix wins because it is small, reduces risk, and affects revenue directly. Small improvements that touch money tend to win under WSJF, which is a feature: they are cheap to start and their value is realized quickly.

How does WSJF compare two items in money terms?

Relative scores are convenient, but the underlying logic is financial, and it is worth seeing once in currency. Consider two jobs with real cost-of-delay rates.

• Job A: costs $3,000 per week of delay, takes 5 weeks.
• Job B: costs $4,000 per week of delay, takes 20 weeks.

Job B has the higher weekly cost of delay. WSJF says do A first because A’s value density is higher: 3,000 ÷ 5 = 600 per week of duration versus 4,000 ÷ 20 = 200.

Now check the arithmetic of the two possible sequences, counting delay cost from today until each job finishes:

Doing the smaller job first saves $40,000 even though the larger job has the higher weekly cost of delay. That is the entire argument for weighted shortest job first, expressed in one table. It also explains why sequencing — not ranking in isolation — is the real decision.

What does a second example look like with real revenue at stake?

Suppose a subscription business has two candidates. An annual-plan upsell is expected to add $18,000 per month once live, with 6 weeks of work. An onboarding email rewrite is expected to save about 40 accounts a month at $35 average revenue, so $1,400 per month, with 2 weeks of work.

Value density: the upsell returns $18,000 ÷ 6 = $3,000 per week of duration; the onboarding rewrite returns $1,400 ÷ 2 = $700 per week. The upsell wins by a factor of more than four, which matches what relative scoring would have said. The difference is that the money version lets you say “delay on this costs $4,500 a week” in a steering meeting — a sentence executives can act on. Relative scores cannot produce it, and that is the main critique of WSJF.

Why is a small, low-value item sometimes ranked above a big, valuable one?

Because cost of delay is incurred per unit of time, not per unit of output. A large item that delivers a lot in eighteen months may destroy more value while waiting than a modest item that ships in three weeks — especially if the modest item unblocks other work.

The model is deliberately biased toward short jobs, and the weighting keeps that bias honest. Pure shortest-job-first minimizes average waiting time but ignores value; WSJF multiplies by cost of delay so a quick, worthless task cannot outrank a quick, valuable one.

There is a real failure mode. If size estimates are systematically optimistic for large items, WSJF under-ranks them, and the organization spends a year shipping small improvements while the platform rots. If every item in the top five is under three weeks, the size column is probably wrong.

When should you not use WSJF?

WSJF is a poor fit in five situations, and using it anyway wastes time.

Team-level story ordering. SAFe’s own guidance notes that WSJF is not well suited to ordering stories inside a sprint. A team of six does not need a formal cost-of-delay model to sequence two weeks of work; it needs a conversation.

Fixed regulatory or contractual dates. A compliance deadline is a constraint. Score it, note it, and schedule it. Ranking it against growth work creates the illusion of a trade-off that does not exist.

Hard dependencies. If item B cannot start until A ships, the sequence is partly determined. WSJF can rank the pair, but it cannot reorder within the chain.

Decisions that require comparing value to cost. WSJF answers “what first”, not “should we build this at all”. A feature with a high WSJF score can still be a bad investment if building it costs more than the delay it avoids. That is an ROI question, and it needs money, not relative points.

Very small personal backlogs. A ten-item list on a solo project is faster to sort by deadline and consequence than to score on four dimensions.

What are the most common WSJF mistakes?

Seven mistakes account for most bad WSJF outcomes.

Scoring row by row. This destroys the relative scale, because each item ends up scored against a different mental anchor. Score column by column.

No 1 in a column. Without a floor, everything inflates and the ratio compresses toward 1, which makes the ranking meaningless.

Product management scoring job size. Size belongs to the delivery team. When leadership sets size, the number reflects what they want the schedule to be rather than what it is.

Comparing scores across backlogs. WSJF scores are relative to one candidate set. A 7.0 in one program’s backlog says nothing about a 7.0 in another’s.

Treating the ranking as the decision. Dependencies, capacity, and fixed dates still apply. WSJF orders candidates; it does not allocate people.

Re-scoring too rarely. Time criticality is the most volatile input. A feature that was not urgent last quarter may be urgent now, and a stale score hides that.

> Common mistake: Running WSJF once, publishing a ranked list, and never revisiting it. The method assumes continuously changing priorities. A frozen ranking is just a prioritized backlog with extra arithmetic.

What are the serious criticisms of WSJF?

The strongest critique is economic, not procedural. Joshua Arnold, who writes extensively on cost of delay, argues that relative value estimates cannot support real trade-off decisions once more than one stakeholder is involved. His alternative — usually called CD3 — estimates cost of delay in money per unit of time and divides by duration in the same units, producing a value-density number with a unit such as dollars per week.

That critique lands. Relative scoring has three genuine weaknesses.

It hides magnitude. A backlog where everything scores between 3 and 8 looks evenly balanced, even if one item is worth a thousand times more than another. Relative scales compress variance by design.

It invites false precision. A WSJF of 4.75 looks like a measurement. It is the output of four subjective judgments divided by a fifth.

It is sensitive to anchors. Change which item gets the 1 and every score shifts. Different facilitators produce different rankings from the same backlog.

Relative WSJF still has a place: it is fast, needs no financial model, and forces a structured conversation about delay that most teams never have. Use it when the organization cannot put money on value, and use CD3 when it can. Using relative scores and pretending they are precise is the only genuinely bad option.

How do you run WSJF without it becoming a ritual?

Four practices keep the method useful after the novelty wears off.

Tie scoring to a planning cadence. Score before each planning increment, not continuously. Continuous rescoring turns into churn; annual scoring turns into fiction.

Keep the scoring session short and structured. Ninety minutes, twenty items maximum, one facilitator, and a rule that disagreements about a score are resolved by picking the lower number and moving on.

Record the reasoning, not just the score. One line per item explaining why time criticality is a 13. Six weeks later, that line is the difference between a defensible decision and an argument about what someone meant.

Review the predictions. Track what happened to the top three items: did the delay cost materialize? Teams that check their cost-of-delay assumptions get better at estimating them.

This is where a workspace matters. WSJF needs scores that live next to the work, not in a spreadsheet that drifts out of sync with the backlog. Doitify is an all-in-one platform for project management, team management, and goal achievement, and its relevant piece here is structural: tasks, sub-tasks, owners, sprints, backlogs, roadmaps, and reports sit in one place, so a WSJF field stays attached to the item as it moves through planning and delivery.

We build Doitify, so treat that as a product note rather than an independent review. A team that already has a working backlog tool and a disciplined scoring session does not need to change anything to use WSJF well.

Conclusion

WSJF answers one question well: given more valuable work than capacity, what should go first? Cost of delay divided by job size gives an answer that survives scrutiny because it is built from explicit judgments rather than seniority.

Use it with three disciplines. Score in columns, anchor every scale at 1, and let the delivery team size the work. Then treat the output as input to a decision rather than the decision itself — because the ranking cannot see your regulatory deadline, your dependency chain, or the fact that your best engineer is on leave.

If this post on wsjf was helpful, you might also enjoy Resource Leveling vs Resource Smoothing: Key Differences and Project Manager vs Program Manager: What’s the Difference?.