Two weeks into the increment, a new request lands. Someone runs the numbers: high Cost of Delay, small job size, and a WSJF score that comfortably beats three items already sitting in the release. The Product Owner does exactly what a well-run SAFe organization is supposed to do — re-scores, re-ranks, moves it up. Nobody objects. There is nothing to object to.

Six weeks later the release is a week late, and nobody can point to the decision that made it late. That is because there wasn’t one. There were eleven, and every single one of them was correct.

WSJF is doing its job. That is exactly the problem.

WSJF — Weighted Shortest Job First — is one of the more disciplined things a SAFe organization does. It forces a team to put a number on the value of time: Cost of Delay divided by job size, so the work that is most expensive to postpone goes first. That is not guesswork. It is a room full of people applying expert judgment to a real economic question.

So is the confidence vote. At PI planning, the team looked at a specific set of items, a specific throughput window and a specific set of people, and said: given this, here is how likely we are to hit this date. Both judgments are sound. They simply answer different questions, and only one of them has a date in it.

WSJF produces an ordering. An ordering has no date in it. The formula is denominated in value per unit of time — WSJF already knows that time is the currency — and it still never tells you how many days a re-rank spends.

Two re-ranks that look identical

In a Jira backlog they are the same gesture: cards move. In the forecast they are not the same event at all.

Re-ordering. You change the sequence of work that was already committed. Total scope is unchanged, so the committed date usually holds — unless the new order pushes something below the cut-line, or reshuffles the sequence so that a dependency now lands later than the plan assumed.

Re-prioritizing in. The higher-scoring item was not in the release. Now it is. That is a scope change, and it arrives with a governance stamp on it. Either something of equivalent size leaves the release, or the date moves. There is no third option — and “we’ll absorb it” is just the second option with the arithmetic left out.

Scope creep with a spreadsheet

Scope creep has a stereotype: the stakeholder who “just” wants one more thing, late on a Friday. A WSJF re-rank has the opposite optics. There is a score. There is a formula. There is a room that agreed. Which is precisely why it never gets named — it is the one form of scope creep that looks like good practice, because it is good practice.

It is the same shape as a change control board approving a change while nobody re-prices the date: a legitimate process producing a sound decision that quietly invalidates the arithmetic behind a commitment. The silence afterward is the failure, not the re-rank.

What it looks like when the arithmetic stays live

Once scope change is a tracked input rather than a feeling, a re-rank becomes readable. Release Management, Roadmaps & Product Portfolio for Jira feeds scope movement into a Monte Carlo simulation over the team’s real throughput, so the P50, P85 and P95 dates react as the release grows or shrinks. Scope change is reported as a rate — a percentage of change and a per-day pace — and it moves in both directions: pull an item back out and the burn-up scope line steps down to match. Because the ranking surface also holds the forecast, re-ranking or moving the cut-line updates the projected date on the spot.

Be equally clear about what the app does not do. It does not compute WSJF scores, it does not store your Cost of Delay or job-size inputs, and it does not rank a backlog outside a Fix Version. The scoring stays where it belongs, with the people who understand the economics; the app takes the ranking you decide on and prices it. (The mechanics are documented in how release-scoped ranking works, and the separate argument for why scoring a 500-issue backlog goes stale is made in full in our case against whole-backlog prioritization.)

Price the re-rank at the moment you make it

WSJF tells you the new item is worth more. The forecast tells you what it costs. Put the two numbers next to each other and the re-rank stops being an assumption and becomes a trade: this is worth nine days of the committed date — still yes?

Often the answer is obviously yes, and now it is a decision the team made on purpose rather than one it discovers at the demo. Sometimes it is no, and something comes out to pay for it. Either way the renegotiation happens in week two, while there is still room to move, instead of in week six when the only remaining variable is the date. That is what it means to protect a committed release date against the three things that erode it: not preventing change, but refusing to let it happen in the dark.

Your next re-rank is going to happen. See what it costs on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.

Frequently asked questions

Does WSJF replace release forecasting?

No. WSJF is a prioritization model: it ranks items by Cost of Delay divided by job size to decide what should be worked next. It produces an ordering, not a date, and it says nothing about how long the ordered work will take or how much confidence a delivery date deserves. Forecasting is the separate step that takes the scope you have ranked and projects it against the team’s real throughput. Teams that run WSJF well still need a live forecast, because the ranking changes far more often than the committed date gets re-checked.

Is re-prioritizing with WSJF the same as scope creep?

It is when the re-rank pulls new work into a release that was already committed. Re-ordering items already in scope changes the sequence; adding a higher-scoring item changes the total. The second is a scope change however well justified the score, and it moves the committed date unless something of similar size leaves. The distinction matters because the two look identical in a backlog and only diverge in the forecast.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio