A backlog of 400 tickets is rarely 400 units of work. In most of the backlogs I've looked at, a third of the tickets are duplicates, stale ideas, or requests from someone who left the company. Another chunk is vague enough that nobody could start it tomorrow. The part that is real, scoped, and still wanted is usually much smaller than the number on the board, and that is the part you should be clearing.
The instinct when a backlog grows is to hire. Sometimes that's right. But if you add engineers before you fix how work flows, you pay for more people to wait in the same queue.
Key Takeaways
- Triage before you hire. Deleting and merging tickets is the fastest backlog reduction there is.
- Little's Law says lead time grows with work in progress. Cap WIP and finished work comes out faster.
- Brooks's law bites hardest on tangled, late work. Add engineers to separable streams, not the critical path.
- Augmented engineers work best on a clearly bounded slice: a bug queue, a migration, an integration backlog.
Step One: Shrink the Backlog on Paper
Block two hours with the product lead and the tech lead. Go through the backlog with three questions per ticket: does anyone still want this, could an engineer start it tomorrow, and is it a duplicate of something else. Close anything that fails the first question. Send anything that fails the second back to whoever filed it. Merge the duplicates.
This feels like cheating. It isn't cheating, because every stale ticket costs something: it gets re-read at every planning meeting, it muddies prioritization, and it makes the team feel permanently behind. A backlog that honestly reflects wanted work is also the only way to know whether you have a people problem at all.
Step Two: Cut Work in Progress
Little's Law is a queueing result from 1961: the average number of items in a system equals the arrival rate times the average time each item spends in it (Little, Operations Research). Rearranged for engineering, average lead time equals work in progress divided by throughput. If eight engineers have 30 tickets open at once, each ticket takes roughly four times as long to finish as it would with eight open, assuming the team's throughput stays the same.
Throughput doesn't change much week to week. WIP is the lever you control. Set a limit per person or per column, finish before starting, and swarm on the oldest in-progress items. We wrote up the mechanics in WIP limits and Little's Law, and the related trap of keeping everyone at full load in why 100 percent utilization slows teams down.
Step Three: Add People Where They Can Absorb Work
Fred Brooks put it bluntly in The Mythical Man-Month: "Adding manpower to a late software project makes it later." He later called that an "outrageous oversimplification," and he was right to (Brooks's law). The law bites when new people need heavy onboarding from the same engineers who are already the bottleneck, and when the work can't be split. It bites much less when the work is separable.
| Backlog type | Add engineers? | Why |
|---|---|---|
| Critical-path feature that is already late | Rarely | Onboarding pulls your best people off the work |
| Bug and small-fix queue | Yes | Independent tickets, fast feedback, good for ramp-up |
| Integration or connector backlog | Yes | Each integration is its own stream |
| Framework or dependency upgrade | Often | Mechanical, testable, easy to review |
| Test coverage and flaky-test cleanup | Yes | Low coordination cost, high long-term value |
| Vague "platform rethink" work | No | Needs decisions first, not hands |
A good pattern is to hand a newly added engineer the separable queue and let your existing team stay on the critical path. The new person ramps on low-risk tickets, and your seniors keep their focus. Brooks's law goes deeper on why this works.
A Concrete Version
A 12-engineer B2B SaaS team has 410 open tickets and a sales team complaining that customer bugs take six weeks to fix.
Week one, the CTO and head of product run the triage. They close 130 stale tickets, merge 40 duplicates, and bounce 55 back for clarification. That leaves 185 real items: 90 customer bugs, 35 integration requests, 20 dependency upgrades, and 40 roadmap features.
Week two, they set a WIP limit of two tickets per engineer, down from an average of about four. Median bug lead time starts falling within the month, with no new people.
Then they look at the remaining math. The 90 bugs and 35 integrations are separable and would keep two engineers busy for most of a quarter. The CTO brings on two senior augmented engineers dedicated to that queue, with one internal engineer as their reviewer for the first three weeks. The core team keeps the 40 roadmap features. By the end of the quarter the bug queue is under 20 and lead time for customer bugs is measured in days. The augmented engineers stay on for integrations, which turned out to be a permanent stream.
The order mattered. Hiring first would have put two more people into a 410-ticket queue with four tickets open per person.
The Honest Counterpoint
Sometimes the backlog is real, the WIP is fine, and the team is simply too small for what the company promised customers. Triage then becomes a way to avoid a hard budget conversation. If after cleanup you still have more wanted, well-scoped work than your team can finish in two quarters, you have a capacity problem, and the signs you need more engineers apply.
The other failure is using a backlog push to dodge prioritization. A team that clears 150 low-value tickets fast has still spent a quarter on low-value tickets. Clearing the backlog is only good if what's left is what matters.
Frequently Asked Questions
How big should an engineering backlog be?
Big enough to cover a few sprints of well-scoped work, plus a clearly separate list of ideas. If it takes more than an hour to review, most of it isn't a backlog anymore.
Will adding engineers to a backlog slow the team down?
In the first weeks, a little, because someone has to onboard them. Give new engineers separable work and a named reviewer, and the dip is short. Put them on a late, tangled feature and Brooks's law applies in full.
Should I use contractors or full-time hires to clear a backlog?
If the backlog is a one-time bulge, contract or augmented engineers fit better, since you won't need them forever. If the triage shows a permanent stream of work, plan for a permanent seat.
The Bottom Line
Delete first, limit WIP second, and add people last, onto the parts of the queue that can absorb them. If you get to step three, Ruzora sends a vetted shortlist of senior engineers within 72 hours. See available engineers or read how to onboard a staff augmentation team before they start.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
