Why Engineering Backlogs Kill Velocity (and What to Do Instead)

Key Takeaways

Atlassian's State of Teams research has consistently found that backlog management is one of the top time sinks for engineering teams.
The alternative to a backlog is not chaos -- it is a binary decision rule.
The backlog is not sacred infrastructure.

Published: February 17, 2026 | PRJ-02 Content

Keywords: engineering backlog problems; reduce software backlog; backlog management alternatives

The Setup

Every software team has one. The backlog -- that ever-growing list of tickets, feature requests, bug reports, and "nice-to-haves" that sits in Jira or Linear, silently expanding while the team sprints through whatever made it to the top. The promise is simple: capture everything, prioritize later, execute in order. The reality is that most of those items will never ship. They will sit, decay, and consume cognitive bandwidth until someone runs a grooming session and quietly archives 60% of them.

The conventional approach treats backlog accumulation as a management problem. If the backlog is too big, you need better prioritization ceremonies. If items are stale, you need more frequent grooming. If the team feels overwhelmed, you need a product owner who can say "no" more often. The tooling ecosystem reinforces this: Jira, Azure DevOps, Linear, and Shortcut all assume the backlog is a permanent fixture. The question is never whether to have a backlog -- it is how to manage the one you have.

This framing misses the structural problem. A well-groomed backlog still carries cognitive weight. A well-prioritized backlog still decays. The backlog is not a management challenge -- it is a category of waste disguised as organization. The question worth asking is whether the backlog itself is the problem.

What the Data Shows

Atlassian's State of Teams research has consistently found that backlog management is one of the top time sinks for engineering teams. Teams report spending significant portions of their sprint cycles on grooming, prioritization, and backlog refinement -- time that does not produce shipped software. The ceremony around the backlog becomes self-sustaining: the larger the backlog grows, the more time is required to manage it, which reduces the time available for execution, which causes the backlog to grow further.

LinearB's engineering metrics data draws a direct line between backlog size and deploy frequency. Teams with larger backlogs show longer cycle times from commit to deploy. The correlation is not surprising once you understand the mechanism: every item in the backlog represents a deferred decision. Deferred decisions accumulate complexity. When a team finally picks up a backlog item from three months ago, they discover that the codebase has evolved, the original context is gone, and the item needs to be re-scoped. The "saved" work of capturing the item is consumed -- and then some -- by the rework of adapting it to current reality.

Basecamp's Shape Up methodology, developed by Ryan Singer, identified this dynamic and proposed a radical alternative: no backlogs at all. Shape Up argues that if an idea is important enough, it will come back. Rather than maintaining an ever-growing list of deferred commitments, teams should bet on shaped work for fixed cycles and let everything else go. The approach eliminates the grooming overhead entirely and forces honest evaluation of what matters now versus what can be released.

The internal data from PRJ-02's portfolio validates this at the individual operator level. Across 10 production systems totaling 596,903 lines of code and 2,561 commits (October 7, 2025 through February 2, 2026), zero formal backlogs were maintained. No issue tracker. No ticket queue. No ranked list of deferred work. No technical debt tickets. No "future consideration" lists. The output trajectory during that period tells the story:

Month	Daily Commit Average	Active Systems
October	6.8	6
November	4.8	4
December	10.0	3
January	31.1	5

January's 31.1 daily commit average across 5 active systems -- with zero backlog overhead -- represents a 4.6x increase from October's starting rate. If backlog management consumed even 5% of operator attention (a conservative estimate for someone managing multiple systems), that January output would have been reduced by approximately 50 commits. Those commits went to execution instead of administration.

The MVP delivery timeline provides further evidence. Early projects (projects 1-3) required 14-21 days to reach MVP. By the late phase (projects 8-10), MVPs landed in 4-5 days. PRJ-04 shipped in 5 active days with 29,193 lines of code. PRJ-03 shipped in 9 days with 5,862 lines of code. Both with zero backlog at any stage. The cognitive overhead that backlog management would have imposed was redirected entirely to building.

How It Works

The alternative to a backlog is not chaos -- it is a binary decision rule. Under the Compounding Execution Model (CEM), every unit of work that surfaces gets one of two outcomes: advance it toward the current target, or stash it as a retrievable asset. There is no third option. No "later" list. No "next sprint" pile. No accumulating inventory of unkept promises.

The distinction between stashing and backlogging is critical. A backlog item says "we need to do this." A stashed asset says "this exists if we need it." The backlog creates obligation. Stashing creates optionality. The psychological difference is immediate: zero deferred commitments means zero open cognitive loops pulling attention away from current execution. Zeigarnik's research (1927) established that incomplete tasks persist in working memory and create cognitive tension. A backlog of fifty items is fifty open loops. Eliminating the backlog eliminates the loops.

This approach requires a healthy storage system. CEM uses Foundation -- a structured repository of patterns, templates, and domain knowledge that grows with each completed project. When an idea surfaces that does not serve the current target, the operator captures the valuable knowledge (a pattern, a snippet, a domain insight) without creating a commitment to execute. The idea is preserved. The obligation is not. Future projects can draw on stashed assets when the context is right, rather than dragging forward a list of stale commitments that no longer match the current architecture.

The mechanism also explains why rework stayed flat or improved across the portfolio. If unaddressed backlog items were degrading system quality, rework would increase over time as deferred issues compounded. Instead, the rework trend across four months and ten systems moved from learning-elevated (October) to stable-to-improving (December-January). No accumulated debt from deferred items.

What This Means for Engineering Leaders

The backlog is not sacred infrastructure. It is a liability that most teams accept as unavoidable because the tooling assumes it and the methodology requires it. The data -- both from external research and from a validated production portfolio -- suggests that eliminating the backlog entirely is not only possible but productive.

For teams evaluating their workflow: measure how much time goes to backlog management versus execution. Calculate the decay rate of your oldest tickets. Check how many backlog items from six months ago are still relevant without re-scoping. If the numbers show what industry benchmarks suggest -- that 60-80% of backlog items are never completed and the rest require significant rework to adapt -- the backlog is not deferring work. It is deferring the decision to reject work. Making that decision immediately, every time, costs less than maintaining the fiction that you will get to it eventually.

References

Atlassian (2023). "State of Teams Report." Engineering team time allocation and backlog management overhead.
LinearB (2023). "Engineering Benchmarks." Backlog size vs. deploy frequency and cycle time data.
Singer, R. (2019). Shape Up: Stop Running in Circles and Ship Work that Matters. Basecamp.
Zeigarnik, B. (1927). "On Finished and Unfinished Tasks." Incomplete task persistence in working memory.
Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
Anderson, D.J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.