You start the month with 40 tickets in your backlog. Your team handles 35. Yet at the end of the month, 52 remain.
The math reveals something important: while the team was closing 35 tickets, 47 new requests were added.
So the problem doesn’t necessarily come from a lack of productivity. A product backlog grows when the volume of new requests consistently exceeds the team’s capacity to handle, reject or remove them.
Before hiring or adding developers, you need to identify what is really unbalancing this flow. Here are the five most common causes and the right solution for each.
Cause 1: no one is really accountable for priorities
Requests come from customers, sales, management, support or internal teams. When no one is clearly responsible for making trade-offs, they all end up in the same place.
The backlog then becomes a waiting list with no real order. Tickets opened eight months ago sit alongside today’s emergencies. Developers work on the best-described, simplest or most insistent topics, but not necessarily on those that deliver the most value.
The solution isn’t necessarily to hire a full-time Product Owner right away. However, responsibility for the backlog must be clearly assigned to someone able to:
- centralize and qualify requests;
- compare their value, urgency and cost;
- arbitrate between the various stakeholders;
- maintain a clear order of priority;
- reject or postpone certain requests;
- close tickets that have become useless.
This responsibility can be held by a Product Owner, a Product Manager, a business lead or the CEO, depending on the size and maturity of the company.
When no one can say no, the backlog no longer reflects the product strategy. It simply accumulates every idea and request expressed over time.
Cause 2: too many requests come in unfiltered
A backlog can keep growing even when priorities are correctly ordered. The problem then comes from the lack of a filter at the entry point.
A request is sometimes turned into a ticket as soon as a customer reports a need, a salesperson passes on an idea or a colleague spots a possible improvement. Yet not all these requests justify development work.
Before adding a ticket to the backlog, you need to determine:
- what problem needs to be solved;
- who actually faces this problem;
- how many users are affected;
- what outcome is expected;
- whether a solution already exists;
- whether the request fits the product strategy;
- what will happen if it isn’t addressed.
The solution is to set up an upstream qualification process. A request can be recorded without immediately entering the development backlog. It must first be analyzed, grouped with similar needs, then accepted, postponed or rejected.
The best way to reduce a backlog isn’t always to develop faster. Sometimes it’s to avoid building features that are rarely used or that have become useless even before they ship.
Cause 3: tickets are vague or too large
A ticket that says “improve the dashboard” is not ready for development. It expresses an intention, but specifies neither the problem to solve nor the expected outcome.
The developer then has to look for the missing information, reach out to several people or make their own assumptions. The ticket stays blocked or produces a result that doesn’t match the need, leading to further corrections.
The same problem arises with tickets that are too large. A feature requiring several weeks of work stays open for a long time, hides real progress and increases the risk of getting stuck.
A ticket that is ready for development should at least specify:
- the user need or problem;
- the expected value;
- the acceptance criteria;
- the main business rules;
- known dependencies;
- what is out of scope.
The solution is to define criteria for entering development and to hold regular refinement sessions. A ticket that isn’t sufficiently understood stays in specification. A topic that is too large is broken down into smaller deliverables that can be developed, tested and validated incrementally.
The Product Owner plays a decisive role here: they turn business requests into priorities that the technical team can understand and act on.
Cause 4: technical debt gradually reduces delivery capacity
Every sprint, the team spends part of its time working around known problems: a module that is hard to change, insufficient tests, a poorly optimized database or deployments that are still too manual.
This work often remains invisible in the functional backlog. Yet it increases the cost of every change and makes production releases riskier.
Technical debt acts as a levy on the team’s capacity. The more it accumulates, the longer a seemingly simple ticket takes.
The most common signs are:
- estimates that increase for comparable features;
- frequent regressions;
- long or risky production releases;
- dependence on a few people who know the existing system;
- components the team is reluctant to change;
- a growing share of time spent on bugs and incidents.
The solution is to make this debt visible, then prioritize it according to its real impact. Issues that regularly slow down development, weaken production or create a security risk must be built into the roadmap.
Regular capacity can be reserved for addressing them, but the percentage should depend on the context. The goal isn’t to “clean up all the code”: it’s to remove the technical blockers that hurt the product and the team the most.
When the source of the slowdown isn’t clear, a technical and delivery assessment lets you examine the code, tests, CI/CD, backlog organization and delivery practices in order to identify the priority causes.
Cause 5: the team’s capacity no longer matches demand
Sometimes the diagnosis is simpler: the company is growing, users are more numerous and requests are multiplying, but the product and technical team hasn’t evolved.
In this case, the problem really is capacity. However, adding developers to a poorly structured organization isn’t enough. It can even increase coordination needs and temporarily slow down deliveries.
Before strengthening the team, you should therefore check that:
- priorities are clearly arbitrated;
- tickets are sufficiently prepared;
- responsibilities are defined;
- developers aren’t constantly interrupted;
- the main technical blockers are known;
- the environment allows new profiles to be onboarded.
If these conditions are met and the workload remains consistently above available capacity, adding capacity becomes relevant.
When local hiring takes several months, bringing in external profiles or building a dedicated team makes it possible to add the necessary skills faster: developers, QA, Product Owner, tech lead or DevOps.
Scaling up should nonetheless remain gradual and match the product’s actual constraints.
How can you tell why your backlog is growing?
The total number of tickets isn’t enough to make a diagnosis. A backlog of 200 items can be under control if it is properly qualified and prioritized. Conversely, a list of 40 tickets can already block a small team.
Several indicators help you understand the situation:
- the number of tickets created and completed each month;
- the average age of tickets still open;
- the time between a ticket’s creation and its production release;
- the number of tickets started but blocked;
- the share of time spent on bugs, incidents and fixes;
- the number of requests removed or made obsolete;
- how often priorities change;
- the split of time between new features and maintenance.
This data lets you distinguish four situations.
The incoming flow is poorly controlled
Many requests are added without qualification or a clear link to the product strategy. You need to strengthen the Product Owner role and formalize the rules for entering the backlog.
Tickets struggle to move forward
Topics stay open for a long time, get blocked or frequently come back for fixes. You need to examine how they are prepared, how they are broken down and how delivery works.
Technical debt slows development down
Every change takes more time and generates regressions. A technical assessment helps identify the components and practices to address first.
Capacity is genuinely insufficient
The backlog is well managed, tickets move forward normally, but the volume of relevant requests remains higher than the team can absorb. Strengthening the team then becomes a consistent response.
Should you remove tickets from your backlog?
Yes. A backlog isn’t meant to keep every request received indefinitely.
A ticket can be closed without being developed when it:
- no longer fits the product strategy;
- is based on a need that was never confirmed;
- affects too few users relative to its cost;
- duplicates another request;
- has become obsolete;
- hasn’t been prioritized for several months;
- could be handled without specific development.
Removing a ticket isn’t a failure. It’s a prioritization decision. A healthy backlog doesn’t contain everything the company might one day build, but the topics it genuinely intends to address.
A monthly or quarterly review lets you close obsolete requests and keep the list from gradually becoming unreadable.
Reducing the backlog doesn’t mean building everything
Trying to artificially bring the backlog down to zero doesn’t make much sense. A product team will always have ideas, needs and improvements to consider.
The goal is rather to maintain a backlog that is:
- aligned with the company’s priorities;
- sufficiently prepared to feed the next sprints;
- cleared of obsolete requests;
- proportionate to the team’s real capacity;
- understandable by business and technical teams.
A growing backlog is therefore not automatically a sign of a team that is too slow. It can reveal a lack of arbitration, insufficient qualification of requests, significant technical debt or a genuine capacity shortfall.
The answer depends on the cause. A Product Owner can regain control of priorities and prepare topics. A technical and delivery assessment can identify the blockers slowing down deliveries. A dedicated team can provide the missing capacity when the organization is already sufficiently structured.
How Etixio can help
When the backlog piles up, immediately adding developers isn’t always the right first decision.
Etixio can start by analyzing your product and technical organization: request management, backlog quality, roles, development processes, technical debt and delivery capacity.
Depending on the findings, we can then step in with targeted support:
- provide a full-time or part-time Product Owner to structure and prioritize the backlog;
- bring in a tech lead to identify blockers related to architecture, testing or deployments;
- improve delivery practices and indicator tracking;
- add the profiles you need to your team;
- gradually build a dedicated team once the capacity need is confirmed.
Your backlog keeps growing and you don’t know exactly why? Let’s talk about your organization and identify the actions to take first.
