WSJF rests on a theorem from 1956, and these are the places its conditions break

If your team ranks its backlog with WSJF (Weighted Shortest Job First), you take each item's cost of delay, the money you lose for every week it isn't shipped, divide it by how long the item takes, and work from the highest score down. That rule has a proof behind it. W. E. Smith proved in 1956 that it gives the cheapest possible order, as long as a few conditions hold. When one of them fails, WSJF can put the wrong item first, and in the worst cases below there is no limit to how much more that order can cost than the best one. Those worst cases are built by hand to show where the limits are. I have no data on how often real backlogs run into them.

Below I show why WSJF works and where it breaks, each with an example small enough to check by hand. Then come two related scores, RICE and ICE, which run into different problems, and then the fixes, which need a spreadsheet and no new tools. Almost none of the math is mine. It comes from operations research, a field that among other things studies scheduling, and most of it has been in print for decades. Practitioner blogs such as Black Swan Farming mention that WSJF goes back to Smith's rule. This essay spells out what the theorems say about the scores product teams use.

The short version, if you use WSJF:

• Where items really are independent, WSJF with real dollar figures gives the best possible order. Keep using it there.
• When a cheap item (a migration, a new API) blocks a valuable one, score them together: their combined cost of delay over their combined time.
• SAFe (the Scaled Agile Framework) scores with relative 1-to-20 points, and those can put the wrong item first even when every score is honest. Now and then, check the top and bottom of the backlog against rough dollar figures.
• When you fill a fixed budget by score, also check whether the single most valuable item that fits would beat the whole slate.

Why WSJF works when items are independent#

Smith was solving a factory problem: one machine, a pile of jobs, and each job costs money for every hour until it is finished. Which order keeps the total waiting cost lowest? His answer, now called Smith's rule, was to sort the jobs by cost per hour divided by job length, highest first. That is WSJF in the form Don Reinertsen gave it for product teams in his 2009 book, The Principles of Product Development Flow: cost of delay per week divided by duration in weeks. A backlog is the same problem. The team is the machine, and the total waiting cost is what you pay: each item's cost of delay times the week it finally ships, added up over the whole backlog.

The proof fits in a paragraph. Take two items that sit next to each other in the plan, A and then B, and swap them. Nothing else in the plan moves. B now ships earlier by A's duration, which saves B's cost of delay times A's duration. A ships later by B's duration, which costs A's cost of delay times B's duration. So the swap saves money exactly when B's cost of delay times A's duration is bigger than A's cost of delay times B's duration. Divide both sides by the two durations and that says B's cost of delay over B's duration is bigger than A's cost of delay over A's duration. In other words, B has the higher WSJF score. So any plan with a higher-scoring item sitting right behind a lower-scoring one can be made cheaper by swapping them, and the cheapest plan must be sorted by score. Plans that differ only in how tied items are ordered cost the same, since by the same calculation, swapping two tied neighbors changes the cost by exactly zero.

The proof is set in Smith's world: one team works on one item at a time and finishes it before starting the next. Inside that world it needs three more conditions, and a real backlog can break any of them:

1. Each item's cost of delay is a steady amount of money per week, the same every week until it ships. A hard deadline, or a market window that closes, breaks this.
2. Each item's duration is known in advance and measures real working time.
3. Items are independent and all ready now: any of them can be started at any time.

The figures don't have to be exact dollars and weeks. If every item's cost of delay is off by the same factor (all in thousands, say, or all doubled), and every duration is off by the same factor too, the order comes out the same. That is also the test for story points. They work as durations only if a point stands for the same amount of working time on every item. If a point means more time on some kinds of work than on others, the proof no longer covers your ranking.

The same guarantee covers any score that always ranks items in the same order as cost of delay over duration. RICE (reach times impact times confidence, divided by effort, as described on Intercom's blog) gets it if reach times impact times confidence is proportional to the real value per week and effort is proportional to the real time. A score that only roughly follows value does not get it.

One dependency breaks it: three jobs#

When some items are waiting on others, there are two natural ways to apply WSJF. One is to rank the whole backlog once, blocked items included, and work down the list, skipping anything blocked. The other is to rank again each time the team finishes something, looking only at the items that are ready to start, and take the top one.

Here are three jobs:

• E, a one-week schema migration, worth nothing on its own.
• H, a one-week feature that loses $1,000,000 a week until it ships. It can't start until E is done.
• D, a 100-week grind worth $1 a week.

E scores 0. D scores $1 a week divided by 100 weeks, which is 0.01. Ranking the whole backlog once puts H on top, but H can't start, and D outranks E, so the team starts D. Ranking only what is ready gives the same answer: at the start H is blocked, so the ranking sees only E and D, and D wins.

The WSJF order costs just under 51 times as much as the best order. Nearly all of that is H's million dollars a week, waiting 100 weeks behind the grind, while the team stays busy the whole time.

Those numbers are extreme so that the gap is easy to see. Ordinary numbers give the same wrong first pick with a smaller gap. Say E is still a one-week migration worth nothing alone, H is a two-week feature that loses $50,000 a week and waits on E, and D is a four-week item worth $5,000 a week. D scores 1,250 and E scores 0, so the team starts D again. In the order D, E, H, D finishes in week 4 and costs $20,000, and H finishes in week 7 and costs $350,000: $370,000 in all. In the order E, H, D, H finishes in week 3 and costs $150,000, and D finishes in week 7 and costs $35,000: $185,000. WSJF's order costs twice as much.

E's value of zero is not what causes this. All that matters is that E's own score is lower than D's; then WSJF picks D first, whatever H is worth. And once there are dependencies, there is no multiple of the best plan's cost that WSJF is sure to stay under (the specialist notes at the end show why).

Every rule that scores an item from that item's own numbers has the same blind spot, RICE and ICE included. Nothing in E's numbers says that H is waiting behind it.

Scheduling research worked on this decades ago. Finding the cheapest order once there are dependencies is hard in a formal sense: no fast method is known that always finds it, and most researchers believe none exists. But methods that always come within a factor of two of the best plan were published by the late 1990s. The notes for specialists at the end name them, and the "What to do" section below has a rough version you can run in a spreadsheet. One of these methods builds on an idea Jeffrey Sidney published in 1975: find the group of items, taken together with everything they depend on, that has the highest combined cost of delay per week of work, schedule that group first, and repeat with what is left. The order inside each group still has to be chosen separately. In the three-job example, E and H together score $1,000,000 a week divided by two weeks, which is 500,000, far above D's 0.01. So they go first.

SAFe's scoring sheet can get it wrong with no dependencies at all#

SAFe (the Scaled Agile Framework) doesn't ask for dollar figures. It splits cost of delay into three parts, user and business value, time criticality, and risk reduction or opportunity enablement, and adds them up. Each part is scored in relative points on the scale 1, 2, 3, 5, 8, 13, 20. SAFe's own article says to score each column relative to the other items in that column, with the smallest item set at 1, so the others are scored as multiples of it. Job size stands in for duration and is scored the same way, and an item's WSJF is the sum of its three parts divided by its size.

Because SAFe adds the three parts to get cost of delay, the examples below take it at its word: each part is a slice of the money lost per week, and the three slices add up to the total. That reading is generous to SAFe. If time criticality stands for a deadline, the cost of delay is not steady from week to week, and Smith's first condition fails before any scoring starts. And SAFe's own article calls WSJF a "prioritization model used to sequence work for maximum economic benefit," which is a claim about money, so it is fair to test it with money. Many teams read the points more loosely than this; the section near the end on what this does and does not show comes back to that.

Here are two features. Both take one week, neither depends on anything, and these are their true costs of delay in dollars per week:

Feature 1 costs more for every week it waits, so it should go first. Now score them SAFe's way. Business value: Feature 2 is the smaller, so it gets 1, and Feature 1 gets 2. Time criticality: Feature 1 gets 1 and Feature 2 gets 3. Risk reduction: 1 each. Every score is exact and on SAFe's scale, so nothing was rounded. Feature 1 totals 4, Feature 2 totals 5, both sizes are 1, and SAFe puts Feature 2 first.

The cause is that each column has its own unit. Here a business value point is worth $100,000 a week and a time criticality point is worth $10,000 a week. Adding the columns treats those points as equal, which quietly gives each column a weight set by whatever its smallest item happens to be. If the smallest items in all three columns have the same dollar value, every item is exactly 1, 2, 3, 5, 8, 13 or 20 times that value in each column, and job sizes are scored the same way, the sum can be trusted. Nothing on the sheet checks any of these.

The scale also has a ceiling and a floor.

The ceiling. No part can score above 20, however many times more valuable an item really is. The example below is a stress test, extreme on purpose; the two-feature example above is the ordinary case. It needs two things at once: the ceiling, and the different unit in each column described above.

Take one hero feature and ten small items, all one week long. The hero loses $100,000 a week, nearly all of it business value. Its time criticality and risk reduction are practically zero, which makes it the smallest item in those two columns, so it scores 1 there. Each small item loses about $1,000 a week in business value. Its time criticality and risk reduction are still small in dollars, but each is 20 times the hero's. SAFe scores every column as a multiple of its smallest item, never in dollars, so each small item gets the top score of 20 in both. Here is the whole sheet:

The hero's business value is 100 times the smallest in its column, but the scale stops at 20. So SAFe puts all ten small items ahead of the hero. Both causes are needed. If the scale went up to 100, the hero would score 100 + 1 + 1 = 102 against 41 and go first. If the hero were not the smallest item in the other two columns, the small items could not reach 20 there.

In the SAFe order the hero's $100,000 a week runs for 11 weeks, which is $1,100,000, and the small items add $55,000. In the best order the hero costs $100,000 and the small items $65,000. So SAFe's order costs about 7 times as much. With a hundred small items and a hero worth 10,000 times one of them, it costs about 67 times as much. Grow the backlog and the hero's value together, and the gap grows with no limit.

The floor. No part can score below 1, so the sheet has no way to say "worth nothing". Work with no value at all still scores at least 3 divided by its size. Josh Arnold pointed out on the Black Swan Farming blog that work with zero value can still get a score in SAFe; this puts a number on the same point.

Dependencies. SAFe's third part, risk reduction or opportunity enablement, looks like the place to give an enabler such as E in the three-job example credit for what it unblocks. It can help, if the people scoring remember to rate E high there. But it is still a relative point score capped at 20, so it cannot say how much is waiting: a million dollars a week behind E counts no more than a much smaller feature would, and nothing on the sheet links E's points to H.

RICE when you fill a budget#

Teams also use RICE to pick a quarter's slate: rank by score and take items until the budget runs out. RICE's inputs are real quantities (people reached, person-months of effort), so it avoids SAFe's problem of adding unlike units. Filling a budget this way has two problems of its own.

The first is that a big item can get squeezed out. Say the budget is 100 person-months. Item A takes 1 month and its value (reach times impact times confidence) is 2. Item B takes 100 months and its value is 100. A's value per month (2) beats B's (1), so A goes in first, and then B no longer fits in the 99 months left. The team gets a value of 2 where 100 was available. The standard fix is one extra check: compare the slate you built against the single most valuable item that fits the budget, and keep whichever is worth more. This is a classical fix for "knapsack" problems (packing the most value into a fixed capacity), and the usual RICE process leaves it out. It doesn't always find the very best slate, but it stops one small item from crowding out a big one like this.

The second is that shared users get counted more than once. RICE counts each item's reach on its own, so a user reached by several items is counted several times. Say ten features each reach the same 1,001 power users, which is overlap at its most extreme, and each takes one month; with impact and confidence set to 1, each scores 1,001 (users reached per month of work). One more feature reaches 10,000 different users but takes ten months, so it scores 1,000. With a ten-month budget, RICE picks the ten features and reaches 1,001 people; the single big feature would have reached 10,000.

The fix has two parts, and this example needs both. Scoring each candidate by the new users it adds per month, beyond those already covered by what you have picked, stops the double counting. On its own it does not rescue this example. The first small feature still wins its round, 1,001 new users a month against 1,000. Every small feature after it adds nobody, and the big feature no longer fits in the nine months left. What rescues it is the same extra check as before: compare the slate against the single most valuable item that fits. That check needs the first part too. If the slate is still valued the RICE way, the ten features add up to 10,010 counted users, which beats the big feature's 10,000, even though they really reach only 1,001 people. With both checks, the big feature wins. A more thorough published version of this method comes with a proven guarantee; the notes for specialists give it.

ICE scores depend on how the scale is numbered#

ICE (impact times confidence times ease, each scored 1 to 10) has a different problem: nobody agrees what a step on the scale is worth. Two people can easily picture different gaps between a 5 and an 8, and the product can give a different answer depending on whose picture you use.

Item A scores (8, 5, 5), which multiplies to 200. Item B scores (5, 8, 8), which multiplies to 320, so B wins. Now suppose the team privately treats an 8 on impact as much bigger than a 5. Once an 8 counts for more than 2.56 times a 5 (that is, 64 divided by 25), A wins. An extreme way to see it is to cube the impact scores, so the scale runs 1, 8, 27 and so on up to 1,000. That changes nobody's judgment about which item has more impact, yet A gets 512 times 25, which is 12,800, and B gets 125 times 64, which is 8,000. Cubing all three columns the same way would leave B ahead. One column is enough, because two people can read just that one column differently. So unless your team has agreed exactly what each step on the scale is worth, the order an ICE ranking gives depends on how the scale happens to be numbered, and it is better used to start a discussion than as a calculation.

What to do#

Within a group of truly independent items, use WSJF with real dollar figures. That order is provably the best, so the work that matters is getting the dollar and duration estimates right.

When an enabler blocks other work, score them as a group: the combined cost of delay of the enabler and the work it unblocks, divided by their combined duration. In the three-job example, E and H together score 500,000 against D's 0.01. If one of the items waiting on the enabler scores lower than the group does, leave it out of the group, since adding it pulls the group's score down. For instance, change the three-job example so that D also has to wait for E. Then E, H and D together lose $1,000,001 a week over 102 weeks of work, a score of about 9,800, far below the 500,000 that E and H score without D. So D stays out of the group: E and H go first, then D. With several waiting items, compare the groups you get by including different ones and keep the one with the highest score. This is a rough, by-hand version of Sidney's idea with no guarantee of its own; the factor-of-two guarantee belongs to the full published methods.

Score again after you split an epic. When an epic becomes a pile of stories, each with its own score, the enabler stories drop back to their own small numbers and sink to the bottom. Recompute the group scores for whatever dependencies survive the split.

Treat SAFe's relative points as a rough guide for discussion. A couple of times a quarter, put rough dollar figures on the top and bottom items of the backlog. If the order looks wrong once there are dollars on it, you have found an inversion.

At budget time, score each item by the new reach it adds per month of effort, given what is already picked, and then compare the finished slate against the single most valuable item that fits. You need both steps.

What this shows and where it stops#

The examples are built to show the worst case. How often real backlogs have a cheap enabler in front of a big payoff, or values spread wider than a 1-to-20 scale can hold, is an open question. The math assumes one team working through items one at a time, with steady costs of delay and known estimates. Several teams working in parallel is a different scheduling problem, which this page does not cover. Many teams use these scores to structure a conversation rather than to compute an order, and the theorems say nothing about that use. They do apply to SAFe's own claim, quoted in the SAFe section, that WSJF sequences work for maximum economic benefit.

How this was made, and what the AI did#

This started as a math paper with its results written up as theorems. I worked on it with Claude, Anthropic's AI model. Claude suggested and drafted the small counterexamples and the proofs and helped draft the text. Before going further, I had a Claude agent check whether the results were new. It ran a dozen web searches across the scheduling literature and practitioner writing. That is a quick check, and a full literature review could turn up more. Every result in the paper with real mathematical content was already published, the core one in 1956. The one exception was the SAFe ceiling example, which no source the search found works out; it is about SAFe's scale, not about scheduling. The search found the link from WSJF to Smith's rule only in practitioner writing, never worked out in an academic paper. The math was known and the missing piece was the link to everyday product work, so I decided to turn the paper into an essay for the people who use these scores. A Claude agent drafted it from the paper. A separate Claude agent then checked it, recomputed every example, and caught a condition missing from the ceiling example, which is now included. The scheduling theorems the page relies on were published, with proofs anyone can look up, and every example here is small enough to redo by hand.

For specialists: precise statements and references

The dependency gap in the first example. The cost ratio grows without bound only if H's loss and D's length grow together. With D fixed at 100 weeks, the ratio tends to 51 however large H's loss; with H's loss fixed at $1,000,000 a week, it stays below about a million however long D gets.

Independent items. The model is one machine (one team) processing one job at a time without preemption, all jobs available at the start, with known durations, and the objective is total weighted completion time, written 1 || Σ w_j C_j, where w_j is item j's cost of delay per week (a constant rate, so cost is linear in finish time), p_j its duration, and C_j its finish time. Smith (1956), the rule known as Smith's rule or WSPT (weighted shortest processing time): a sequence is optimal if and only if it is in nonincreasing order of w_j / p_j (two such orders differ only by adjacent swaps of tied items, each of which leaves the cost unchanged). Any score that is a strictly increasing function of w_j / p_j yields an optimal sequence; in particular, multiplying every w_j by one positive constant and every p_j by another changes nothing. A score that is only non-strictly monotone can merge distinct ratios into ties, and an arbitrary tie-break can then lose optimality. RICE is covered when reach × impact × confidence is proportional to w_j and effort is proportional to p_j.

Precedence constraints. Greedy WSJF is list scheduling: whenever the machine is free, start the available item with the largest w_j / p_j. On this instance a single static ranking that skips blocked items gives the same sequence. Instance: E (w = 0, p = 1), H (w = M, p = 1, requires E), D (w = 1, p = T). Greedy runs D, E, H; the optimum runs E, H, D. With M = 1,000,000 and T = 100 the costs are 102,000,100 and 2,000,102, a ratio of 50.997. For fixed T the ratio tends to (T + 2) / 2 as M grows; for fixed M it is capped at M + 1 as T grows; with M = T² it is at least T / 4, so it is unbounded (no constant approximation ratio). Any w_E from 0 up to but not including 1 / T gives the same greedy choice, so no tie-breaking rule is involved. The minimization problem 1 | prec | Σ w_j C_j is strongly NP-hard (Lawler 1978; Lenstra and Rinnooy Kan 1978). Ratio-2 algorithms exist: an LP-based one (Hall, Schulz, Shmoys and Wein 1997) and a combinatorial one built on Sidney's decomposition (Chekuri and Motwani 1999). Sidney (1975) decomposes the instance into ratio-maximal initial sets (precedence-closed sets S maximizing w(S) / p(S)). The "score the enabler with what it unblocks" advice above is a heuristic in the spirit of Sidney's rule, not his algorithm: the ratio-maximal initial set can be a strict subset of the enabler and its successors, and the heuristic carries no approximation guarantee of its own. In the example with D also requiring E, the precedence-closed sets are E alone, E with H, E with D, and all three, with ratios 0, 500,000, 1/101 and 1,000,001/102, so E with H is ratio-maximal.

SAFe's sheet. Each cost-of-delay column k is divided by its own minimum m_k, so the summed score is Σ_k c_jk / m_k, a weighted sum with weights 1 / m_k. If the m_k are equal and every ratio c_jk / m_k is on the scale (and likewise for size), the sheet's order is the true order. Unequal minimums can invert it on independent, truthfully scored items: the two-feature example has column minimums 100, 10 and 10 (thousands of dollars a week). Ceiling: n distractors and one hero, all of size 1, with n at least 5 so the cap binds; the hero has business value X = n² and time criticality and risk equal to ε, and each distractor has business value 1 and time criticality and risk equal to 20ε. Scores are 22 for the hero (capped) and 41 for each distractor, so all n distractors go first. As ε tends to 0 the cost ratio to optimal is 7.0 at n = 10, 67.0 at n = 100 and 667.0 at n = 1000: Θ(n), unbounded. The main-text tables are the n = 10 case with values in thousands of dollars a week and ε taken to 0. Floor: every column score is at least 1, so an item whose true cost of delay is arbitrarily close to 0 still scores at least 3 / size; the scale cannot express zero value. This formalizes Arnold's point.

RICE selection. Descending-score selection under a budget is ratio-greedy knapsack, with unbounded worst case (budget B, a unit item of value 2, an item of size and value B). The classical repair takes the better of the greedy slate and the single best item. With overlapping audiences, true reach is a coverage function and selection is budgeted maximum coverage, which is NP-hard; greedy on incremental reach with partial enumeration (it also tries small starting sets of items before the greedy pass) achieves a (1 - 1/e) guarantee (Khuller, Moss and Naor 1999): it always reaches at least about 63 percent as many users as the best possible slate. That figure is for their version with partial enumeration, which is the "more thorough published version" in the main text, not for the two simpler checks described there. Plain incremental-reach greedy without that step fails on the page's example (it takes one small feature first, after which the big one no longer fits); paired with the single-best-item comparison it recovers the big feature. In requirements engineering this selection problem is the Next Release Problem (Bagnall, Rayward-Smith and Whittley 2001).

ICE. Read as ordinal, a product of scores is not invariant under a strictly increasing rescaling of one input scale; the cube example above flips a pair, and in that pair any rescaling f of the impact scale with f(8) / f(5) above 64 / 25 flips it.

References

• W. E. Smith, "Various optimizers for single-stage production," Naval Research Logistics Quarterly 3(1-2), 1956, pp. 59-66. doi↗
• J. B. Sidney, "Decomposition algorithms for single-machine sequencing with precedence relations and deferral costs," Operations Research 23(2), 1975, pp. 283-298. doi↗
• E. L. Lawler, "Sequencing jobs to minimize total weighted completion time subject to precedence constraints," Annals of Discrete Mathematics 2, 1978, pp. 75-90. doi↗
• J. K. Lenstra and A. H. G. Rinnooy Kan, "Complexity of scheduling under precedence constraints," Operations Research 26(1), 1978, pp. 22-35. doi↗
• L. A. Hall, A. S. Schulz, D. B. Shmoys and J. Wein, "Scheduling to minimize average completion time: off-line and on-line approximation algorithms," Mathematics of Operations Research 22(3), 1997, pp. 513-544. doi↗
• C. Chekuri and R. Motwani, "Precedence constrained scheduling to minimize sum of weighted completion times on a single machine," Discrete Applied Mathematics 98(1-2), 1999, pp. 29-38. doi↗
• S. Khuller, A. Moss and J. S. Naor, "The budgeted maximum coverage problem," Information Processing Letters 70(1), 1999, pp. 39-45. doi↗
• A. J. Bagnall, V. J. Rayward-Smith and I. M. Whittley, "The next release problem," Information and Software Technology 43(14), 2001, pp. 883-890.
• D. G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009.
• Scaled Agile, Inc., "WSJF (Weighted Shortest Job First)," SAFe framework article, archived 19 January 2025↗.
• S. McBride, "RICE: Simple prioritization for product managers," Intercom blog, 5 January 2018. link↗
• J. Arnold, "SAFe and Weighted Shortest Job First (WSJF)," Black Swan Farming blog. link↗

@misc{orden2026wsjfpractitioneressay,
  author       = {Tyler Satchel Orden},
  title        = {WSJF rests on a theorem from 1956, and these are the places its conditions break},
  year         = {2026},
  howpublished = {Cyborg Mathematics},
  url    = {https://cyborgmathematics.com/writing/wsjf-practitioner-essay}
}