Prioritise work by dividing Cost of Delay (user value + time criticality + risk reduction) by job duration to maximise economic throughput. Developed by Reinertsen / SAFe. A structured approach to planning decisions.
What is the economic cost of not shipping each item, and which should go first?
Backlog Items: feature entries to evaluate
User/Business Value: metric entries to evaluate
How much value decays if delivery is delayed (deadlines, competition, seasonal windows)
Risk Reduction / Opportunity Enablement: metric entries to evaluate
Estimated effort (story points, t-shirt size, or person-weeks)
Opportunities scored on the same WSJF (Weighted Shortest Job First) inputs as features.
(user_value + time_criticality + risk_reduction) / job_sizeWSJF, Weighted Shortest JobJobUserJob To Be Done: what the user is trying to accomplishView reference → First, is a sequencing formula: it divides the Cost of Delay of a job by its size, and tells you to do the work with the highest ratio first. It is the operational form of a result from queueing theory, that when jobs compete for the same capacity, ordering them by cost of delay over duration produces the lowest total economic cost.
The underlying principle comes from Don Reinertsen and his work on product development flow, which showed that Weighted Shortest Job First is the economically optimal sequencing rule under realistic conditions. It reached a mass audience through the Scaled Agile Framework, which adopted WSJF around 2011 as its default method for ordering featuresFeatureProduct SpecificationA product capability or featureView reference → and capabilitiesCapabilityStrategyAn ability that enables value deliveryView reference → in a programme backlog. SAFe pairs the formula with relative estimation on a Fibonacci scale, which keeps the scoring fast and comparative rather than falsely exact.
WSJF and Cost of Delay are often discussed together because WSJF is Cost of Delay made operational: Cost of Delay answers how expensive waiting is, and WSJF folds in job size to answer what to do first with finite capacity.
The formula is: WSJF = Cost of Delay ÷ Job Size. Cost of Delay is itself the sum of three relatively scored components:
Components are scored relatively, usually on a Fibonacci scale (1, 2, 3, 5, 8, 13, 20), by comparing candidates against each other rather than against an absolute standard. The smallest item on any axis anchors at 1.
A worked example. A team sequences three backlog items on a 1 to 20 Fibonacci scale. A single sign-on integration scores business value 8, time criticality 13 (a key enterprise deal depends on it this quarter), risk reduction 5, for a Cost of Delay of 26, against a job size of 13: WSJF is 2.0. A dashboardDashboardData & AnalyticsAn analytics dashboardView reference → refresh scores value 5, time criticality 2, risk reduction 2, Cost of Delay 9, against a job size of 3: WSJF is 3.0. A data-export tool scores value 8, time criticality 3, risk reduction 8, Cost of Delay 19, against a job size of 5: WSJF is 3.8. The data-export tool goes first, even though the sign-on work has the highest raw Cost of Delay, because its smaller size makes it the more economical use of the next slot of capacity. That inversion is exactly what WSJF exists to reveal.
WSJF suits a backlog of comparable items competing for the same constrained capacity, where both value and effort vary meaningfully across candidates. It is well matched to programme-level planning, where dozens of features must be ordered and the decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → has to be defensible to people who were not in the estimation session.
It is a poor fit when items are not substitutable, when one piece of work is strategically mandatory regardless of its ratio, or when job sizes are unknowable because the work is genuinely novel. The common failure modes are inflating every time-criticality score until the axis stops discriminating, and arguing over a WSJF of 2.0 versus 2.1 as if the second decimal carried information. The ratio orders the queue; it does not certify the estimates that produced it.
WSJF is a planning framework. The work it sequences is modelled as FeatureProduct SpecificationA product capability or featureView reference → and featureOpportunityDiscoveryA validated gap worth solvingView reference → entities, each carrying the scoring inputs:opportunity
metricMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → inputs that sum to Cost of Delay.metricMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → input capturing relative effort.WSJF shares its inputs with cost-of-delay: value, time criticality, and risk reduction are the same three components. An item scored for one is already scored for the other, so a backlog can be reordered by either method as a view change rather than a re-estimation. The graph holds the judgement once and lets the formula vary.
Sequencing three backlog items
A team scores three candidate jobs on a Fibonacci scale. Cost of Delay (user value plus time criticality plus risk reduction) comes out as 13 for a compliance fix, 21 for a checkout improvement, and 8 for a settings redesign; job sizes are 3, 8, and 5 respectively. Dividing gives WSJF of about 4.3, 2.6, and 1.6, so the small compliance fix is done first despite the checkout having the highest raw Cost of Delay, because doing the shortest valuable job first maximises economic throughput.
Why a smaller job jumps the queue
Two features have identical Cost of Delay of 20, but one is sized at 5 and the other at 13, giving WSJF of 4.0 versus about 1.5. The formula sequences the smaller job first, because under shared, finite capacity the queueing-theory result holds that cost of delay over duration minimises total economic cost. The relative Fibonacci scoring keeps the estimate fast and comparative rather than implying false precision.