Why your backlog never shrinks and how to unlock your team's delivery speed

You look at your team's backlog and feel a familiar unease: it never shrinks. For every item delivered, two new tasks appear. The team works, sprints go by, meetings happen — and yet the feeling is of running on a treadmill. This scenario is not a matter of effort. It is a matter of system.

In over 20 years advising technology companies — from fintechs like BTG and XP to platforms like Livelo and MaxMilhas — I have seen this pattern repeat itself across organizations of all sizes. The problem rarely lies in the individual competence of developers. It lies in the way work is organized, prioritized, and unblocked. And the good news is that there is a structural solution.

The backlog is not the problem. It is the symptom.

The first trap is treating the product backlog as an enemy to be defeated. It is not. A backlog will never reach zero — and it should not. The real problem is when the backlog grows faster than the team can deliver, creating a demand debt that paralyzes decisions and demotivates teams.

There is a concept rarely used outside high-performance engineering environments: the relationship between input rate and engineering throughput. If your team delivers 20 items per month and receives 35 new requests in the same period, the backlog grows by 15 items per cycle. In six months, you have 90 accumulated items that never existed before. In a year, the situation is out of control.

According to data from the 2023 DORA (DevOps Research and Assessment) report, high-performance teams deploy code to production multiple times per day, with a failure rate of less than 5%. Low-performance teams take between one month and six months for a single significant delivery. This difference is not about talent — it is about process, architecture, and management.

Why throughput stalls: the five real blockers

When I analyze a team's delivery speed for the first time, I systematically map the friction points. In most cases, blockers fall into five categories:

• Unmanaged dependencies: Tasks that appear independent but require another team, system, or approval to move forward. When no one maps these dependencies in advance, the item stalls in the middle of the sprint without anyone knowing exactly why.
• Excessive unplanned work: Critical bugs, urgent requests from the CEO, production incidents — these items consume, on average, 30 to 40% of the actual capacity of teams that have no process to absorb them without destroying their planning.
• Insufficient refinement: Poorly written stories reach development with ambiguities that generate rework. A McKinsey study points out that up to 25% of engineering time in mid-sized companies is lost to rework due to unclear requirements.
• Code review as a bottleneck: In many Brazilian organizations I have worked with, pull requests remain open for three, four, sometimes seven days without review. The developer moves on to another task, loses context, and when they return to make adjustments, the cognitive cost has tripled.
• Unstable environments: Broken pipelines, staging environments that do not reflect production, manual deploys — each of these elements adds invisible friction that accumulates into hours lost every week.

What is curious is that most leaders I speak with know these problems exist. What is missing is the priority to address them, because the pressure for new features always seems more urgent than fixing the system that produces them.

The capacity fallacy: why hiring more does not solve it

The instinctive response of many CTOs and founders when the backlog grows is to hire more developers. It is an understandable decision, but frequently misguided — at least as a first measure.

Fred Brooks described this in the 1970s in the classic The Mythical Man-Month: adding people to a late project makes it later, at least in the short term. The reason is that new members need onboarding, consume the time of senior engineers, and increase communication complexity exponentially.

In practice, I have seen this happen at a mid-sized national fintech: the engineering team doubled in 18 months — from 40 to 80 people — and delivery speed dropped by 15%. The reason? The team structure, processes, and architecture were not adapted to support the scale. More people entered a dysfunctional system and made it more dysfunctional.

This does not mean that hiring is wrong. It means that hiring without first unblocking the systemic bottlenecks is throwing money at a structural problem. The real return comes when you increase throughput per person, not just the number of people.

How to unlock delivery speed in practice

Unlocking dev team productivity requires a three-pronged simultaneous approach: visibility, flow, and culture. Here are the levers that consistently generate results:

1. Measure what matters, not what is easy to measure. Most teams measure story points or sprint velocity — metrics that say little about real impact. Start measuring lead time (time from an item entering the backlog to going to production) and cycle time (time from the start of development to delivery). These numbers reveal where work actually stops.

2. Implement WIP limits (Work in Progress). Limiting the number of items in progress simultaneously seems counterintuitive, but it is one of the most powerful levers in technology team management. Teams that work on too many things at once finish few of them. Setting a WIP limit per kanban stage forces the team to finish before starting — and this alone can reduce lead time by 40 to 60% within eight weeks.

3. Reserve explicit capacity for unplanned work. If your team does not have a formal buffer for incidents and urgent requests, that work will invade the planned work regardless — just chaotically. Allocating 20 to 30% of capacity to absorb the unexpected is not waste. It is resilience engineering applied to process.

4. Reduce the size of work items. Large items are enemies of flow. A feature that takes three weeks to deliver is a feature that generates no feedback for three weeks, that blocks the branch for three weeks, and that, if wrong, will generate three weeks of rework. Learn to slice stories into smaller, independent deliveries. Mature teams deliver items that take one to three days, not weeks.

5. Create an explicit refinement process. Before an item enters the sprint, it must be clear enough for any member of the team to develop it without relying on constant clarifications. Invest quality time in defining acceptance criteria, mapping dependencies, and estimating effort. Every hour invested in refinement saves four hours of rework — it is one of the clearest cost-benefit relationships in software engineering.

6. Treat code review as a critical activity, not an optional one. Define internal SLAs for PR reviews — for example, every review must be completed within 24 hours at most. This requires a cultural shift, but the impact on cycle time is immediate. One of the practices I recommend most is the code review office hour: a fixed slot in the day where reviews are collectively prioritized.

The role of leadership: unblocker or bottleneck?

There is a dimension of delivery speed that no tool or process can solve alone: leadership behavior. In many organizations, the CTO or VP of Engineering — with the best intentions — becomes the team's biggest bottleneck.

This happens when relevant technical decisions require the leader's approval. When the team has no autonomy to choose approaches within a safe decision space. When every architectural change requires a meeting with the manager. This pattern of centralization is understandable in small teams, but it is fatal in growing ones.

High-performance teams are not those with the smartest leader. They are those where the leader creates the conditions for people to make good decisions without depending on them all the time.

The most effective practice I have seen work is the explicit creation of autonomous decision domains: a clear map of which decisions the team can make on their own, which require alignment, and which require approval. This removes ambiguity, accelerates flow, and develops team maturity over time.

What to expect when you start fixing the system

An honest warning: when you begin applying these changes, the first visible effect may be a temporary drop in perceived velocity. This is normal. The team is learning new behaviors, questioning old habits, and still carrying accumulated technical and organizational debt.

In general, the first measurable results appear within four to eight weeks. Reduced lead time, less rework, more predictable sprints. Within three to six months, teams that implement these changes consistently tend to show a 40 to 80% increase in actual delivery speed — not in story points, but in features working in production.

More important than the numbers: the team begins to work with less anxiety, more focus, and a greater sense of progress. This has a direct impact on talent retention — which, in the Brazilian technology market in 2024, where the shortage of senior professionals is critical, is worth as much as any productivity gain.

The question you should be asking

Before closing, I want to leave a practical reflection. Most technology leaders who come to me are asking the wrong question. The question is usually: "How do I make my team deliver faster?" The right question is: "What is preventing my team from delivering at the pace it is capable of?"

These are different questions. The first assumes the problem is effort. The second assumes the problem is the system. And systems have leverage points — places where a small change generates a disproportionate impact.

The product backlog that never shrinks is not an inevitability of working in technology. It is a signal that the work system needs to be redesigned. And that, unlike hiring ten senior engineers, is entirely within the control of whoever leads the team.

If you have read this far, it is because this problem is real for you. Perhaps you are facing a growing backlog, a team that works hard but delivers little, or a business pressure that the current system simply cannot absorb. These are the scenarios I work in — and where an external perspective, with method and experience accumulated across dozens of organizations, can make the difference between yet another quarter of unfulfilled promises and a real performance turnaround. Get in touch and let's talk about what is blocking your team's delivery.