Too many teams realize they’re in trouble after it’s too late. “The eleventh hour,” so to speak, is too late.
You’ve been shipping the whole time. Demos land, the feature burn-up climbs, nobody misses a commitment. Then an engineer finally wires the account-deletion path through to the event log and realizes the log is immutable; it holds eleven months of PII, and there’s no way to honor a deletion request without rebuilding the system's spine.
Nobody was negligent. Nobody skipped a step. The backlog was ranked every quarter by the formula everybody agreed to use, and the ranking was correct.
This isn’t the process breaking down. This is the process working as designed. But it lets deeply impactful risks through too often. We need a better process.
If you’re new, welcome to Customer Obsessed Engineering — where I write about making the hard things in tech easy. Learn more.
I don’t want to throw stones from a glass house, so let me make the case for Weighted Shortest Job First before I start taking it apart.
WSJF makes teams talk about the cost of delay. The problem is, most organizations never price delay. They argue about effort, they argue about headcount, they rarely ask what a month of waiting actually costs. Any practice that forces that conversation earns its place. It’s a defense against the loudest voice in the room, which in many organizations sets priority.
A WSJF score is harder to override than a hunch, because it arrives with its arithmetic attached — cost of delay over job size, in public, where anyone can check the work. I’ve watched roadmaps get rearranged by a vice president’s weekend reading more times than I care to count. And the math underneath is sound. Given a queue, sequence changes the cost of the queue, and doing short high-value work ahead of long low-value work is right.
So the formula isn’t the problem. What happened to it on the way into the framework is the problem.
What Reinertsen actually wrote
WSJF didn’t start in SAFe. It comes from Don Reinertsen’s The Principles of Product Development Flow, and in the original it isn’t a ranking system. It’s one of three scheduling rules, each answering a different situation: when delay costs are alike, do the shortest job first; when durations are alike, do the highest cost-of-delay job first; and when neither is alike, use WSJF.1
Read that again. WSJF answers a conditional question. It’s what you reach for under a specific set of circumstances, sitting alongside two other rules for other circumstances. Somewhere between the book and the framework it stopped being a conditional and became a standing quarterly ritual.
Two other things went missing in that translation.
The first is quantification. Reinertsen’s economic principle is blunt: if you only quantify one thing, quantify the cost of delay. He means money. Actual currency, attached to actual weeks. What SAFe asks a room to do instead is score three relative proxies — user and business value, time criticality, risk reduction and opportunity enablement — on a modified Fibonacci scale, and add them together. Three guesses summed is not a quantified cost of delay. It’s a mood, expressed in numbers (which makes it feel more scientific than it is).23
The second is duration. Reinertsen’s formula divides by how long the job takes. SAFe divides by job size, and says so plainly: job size “can be used as a good proxy for the duration,” while conceding in the same breath that “job size is not a perfect proxy for job duration.” That concession costs more than it appears to, which is why we’ll come back to it in a bit.4
There’s one more line in the book worth thinking about, because it’s the one nobody quotes at PI planning. Reinertsen’s Principle F18: priorities are inherently local. It appears four pages after the WSJF principle that everyone cites.5
How WSJF buries the risks
Here’s what makes projects go off the rails late in the game.
Start with the denominator. The work that eliminates the riskiest unknowns is nearly always large — an event backbone, a deletion path through immutable storage, a tenancy model, an integration with the system of record nobody has permission to touch. In other words, it’s hard, structural work more often than not. And, because size stands in for duration, every one of those lands with a fat divisor. The formula penalizes them for exactly the property that makes them worth doing early: they’re hard, and nobody has done them yet.
Now the numerator. A room ranks what it can picture as tangible and valuable. “Users can log in on the new platform” is easy to picture. “Prove we can honor a deletion request against an immutable log” is, conceptually, a detail. There is no moment in the review where somebody says, “Ooh, I love that.” So it gets a low number from people who are being entirely sincere.
SAFe knows about this, which is why risk reduction and opportunity enablement is in there at all. It’s the patch, the band-aid. But look at where the patch sits: it’s a summand, one of three terms added together to make the cost of delay. Sum it with business value and time criticality and it gets averaged into irrelevance by two components that will always score higher on work somebody can see. I have never once watched risk reduction win that argument. Not in a scoring session, not after a VP read through a spreadsheet.
The deeper trouble is that the formula has no way to think about what tackling risk early actually buys: information. Reinertsen is explicit that the value of information is its expected economic value, and he spends a chapter on why getting rid of uncertainty is worth paying for — payoff asymmetries let variability create economic value, and a high probability of failure doesn’t mean bad economics. Finding out in month two that your event log can’t support deletion is a cheap, enormously valuable outcome. Finding out in month eleven is the same information at fifty times the price.67
A WSJF score can’t hold any of that. It’s computed once, against a static picture of the work, and an option’s value comes from what you learn before you have to commit. You cannot price an option with a number you calculated last quarter.
This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.
Risk-first is a phase, not a religion
I want to be careful here, because the opposite mistake is real and I’ve seen it wreck teams too.
Take “build the risky things first” as an absolute and you get six months of platform work with nothing your customer can use. You get architecture astronautics, a beautifully abstracted foundation for a product nobody has validated. You get risk theater, where a team performs de-risking because it’s more comfortable than shipping something a customer might not like.
