Somewhere in most release plans there is a feature everybody privately knows should be cut. It has consumed four sprints, it is not close to done, the original business case has weakened, and the honest move is to stop. It will ship anyway — late, half-finished, dragging the release date behind it — because of the four sprints already spent.
That is the sunk cost fallacy in agile delivery: continuing to invest because of what has already been spent rather than what remains to be gained. Its organizational cousin, escalation of commitment, is the pattern where a group keeps doubling down on a course of action as the evidence against it accumulates. Money and effort already spent are gone regardless of what you decide next. Only the remaining cost and the remaining value should enter the decision. Almost nobody manages this, and agile teams have some specific reasons why.
Why agile delivery is unusually exposed
Agile is supposed to be the antidote. Short iterations exist precisely so you can change your mind cheaply. In practice several forces push the other way.
- Visible partial progress. A half-built feature sits on the board in “In Progress,” 60% complete, every single day. Sunk costs that stay visible are far harder to write off than sunk costs on a spreadsheet, and the closer a piece of work looks to completion, the stronger the pull to finish it.
- Public commitment. The scope was committed in PI planning, in front of stakeholders, with a fist of five. Reversing a commitment made publicly costs social capital that quietly finishing it does not.
- No standing decision point. Sprint reviews ask “is this done?” Retrospectives ask “how did we work?” Neither routinely asks “should we still be doing this at all?” Without a scheduled moment to kill work, work does not get killed.
- Identity. The person who championed the feature and the people who built it experience cutting it as a judgment on them. Escalation of commitment is strongest when the decision-maker also owns the original decision.
The tell
There is one reliable diagnostic. Listen to how the work is defended in planning. If the justification is forward-looking — “customers are waiting on this, it unblocks the integration, it closes a competitive gap” — the decision is sound whether or not the work is late. If the justification is backward-looking — “we have already put four sprints into it,” “we can’t waste that work,” “we’re too far in to stop now” — you are watching the fallacy operate in real time.
A second tell: nobody can state what would have to be true for the team to stop. If there is no condition under which the work gets cut, it was never really a decision.
Four mechanics that make cutting normal
1. Set the kill criteria when you commit, not when you are in trouble. At the moment scope enters a release, write down what would justify dropping it — a cost threshold, a date, a validation that fails. Deciding in advance, while nobody is invested, is dramatically easier than deciding under pressure. This is the same logic as a premortem, applied to scope rather than schedule.
2. Re-ask the question with fresh framing. The standard reframe: knowing what we know now, if this work did not exist yet, would we start it today? If the answer is no, the only argument for continuing is the sunk cost. Run this on the two or three largest in-flight items every time you re-plan.
3. Separate the decider from the champion. Escalation of commitment weakens sharply when the person evaluating the work is not the person who originally sponsored it. A peer product manager or a second team lead reviewing continue-or-cut decisions is a cheap structural fix.
4. Price the cut in days, immediately. The reason teams avoid the conversation is that the cost of continuing is diffuse and the cost of stopping feels concrete. Invert it. If keeping a feature moves the release date by eleven days, say so, in the meeting, in days. Concrete trade-offs get decided; vague ones get deferred, and deferral is how doomed scope survives.
Making the trade-off visible in Jira
Point four is where most teams stall, because nobody in the room can say what the feature costs the date. The scope debate stays abstract, the sunk cost argument wins by default, and the slip shows up two months later.
Advanced Release Planning, Roadmaps & Management for Jira forecasts the release date from real delivery history and capacity, so removing scope produces an immediate, visible change in the forecast date and confidence. That converts “should we cut this?” from a values argument into an arithmetic one — eleven days and four points of confidence against whatever the feature is worth. It also means the decision to keep it is recorded as a deliberate trade-off rather than an omission.
The point
Cutting scope that is no longer worth its remaining cost is not a failure of the plan; it is the plan working. Teams that cut visibly and early build more credibility on dates than teams that finish everything they ever started — late. Decide the kill criteria up front, re-ask the fresh-start question at every re-plan, and price every trade-off in days.
Part of our guide: this article is a deep dive from the complete guide to release planning for Agile teams in Jira. See also managing release scope creep for the pressure coming the other way, how to measure scope creep before it moves your date, and the planning fallacy for the bias that set the optimistic estimate in the first place.
Leave a Reply
Your email is safe with us.