AI backlog grooming, except the tickets get done

Every team has the tail: the thirty to fifty tickets at the bottom of the backlog that will never be scheduled. Papercut bugs, missing tests, small DX fixes, dependency bumps. Everyone agrees they're real, and nobody will ever pick them up; the quarterly ritual of re-ranking them changes nothing. Most of what gets sold as AI backlog grooming is that same ritual, faster: a model labels and re-sorts the pile. The pile remains. The version worth your time is the one where the tickets get done.

The tail exists for an honest reason: none of those tickets is worth a context switch. Fixing the misaligned tooltip is twenty minutes of work inside an afternoon of overhead. You stop the current task, reload that corner of the repo into your head, make the change, wait for CI, open the PR, switch back. No individual ticket justifies that, so no individual ticket ever wins.

The cost isn't zero, though. Each one is a papercut a user still hits, a test that still doesn't exist, a sharp edge every new hire finds again, a quiet signal that the small stuff doesn't matter here. The tail is quality debt and morale debt at once: a list of things everyone knows are broken and has agreed, silently, to keep.

The economics changed

That math held as long as the only way to fix a ticket was an engineer's afternoon. It stops holding when the fix is a sandbox run. Hand the ticket to a background coding agent and the overhead disappears into the agent's side of the loop: it checks out the repo in an isolated sandbox, makes the change, opens a draft PR, and runs your test command before marking it ready for review. Your part is the ten minutes to tighten the ticket and the ten to review the diff, both of which slot into time you already spend on tickets and reviews. Nobody context-switches, because nobody loads that corner of the repo into their head except the reviewer, briefly, with a diff in front of them.

The cash cost is small too. On Sinatra's free tier you get five tasks a day on your own API key, and there's no markup on tokens on any tier (see pricing). A papercut fix costs its tokens plus your review minutes. The afternoon it used to cost was the expensive part, and that's the part that goes away. The PR is still the gate, so delegating a ticket never means merging unread code; it means the reading is all that's left of your side.

Which tickets qualify

The tail isn't uniform. The tickets worth delegating are the ones with a clear repro or a clear gap, and a done-condition someone can observe without reading the diff. Contained scope matters too: one corner of the codebase, not a change that ripples across services. "The retry helper has no tests." "The 404 page still shows the old logo." "The /users endpoint has no pagination." "CI is flaky on the datetime test everyone retries past." An agent can pick any of those up cold, because the ticket itself says what done means.

Most tail tickets aren't in that shape yet; they were written in ten seconds by someone annoyed. Tightening one takes about ten minutes: retitle it to name the behavior, add the repro, write two or three acceptance criteria. The full anatomy is in how to write tickets for AI agents, and it's the highest-return ten minutes in this whole exercise.

Which tickets don't

Skip the design-heavy ones, where the ticket is really an unresolved discussion; the cross-service ones, where the blast radius spans repos and teams; the politically loaded ones, where the code change is trivial and deciding whose workflow is "correct" is not; and anything that needs production access, which an agent shouldn't have. These aren't worse tickets. They're tickets whose bottleneck is judgment or coordination, and delegating them just moves the argument into a PR thread.

What AI backlog grooming looks like in practice

Pick three tickets from the tail each week. Tighten each into an agent-ready spec, assign them, and review the PRs as they land, inside the review time you already budget. Three a week is unheroic on purpose. It never creates a review pile, and it still retires the tail at a pace the tail has never seen: a fifty-ticket tail is gone in a few months, as a side effect of normal review, without a cleanup sprint ever appearing on the roadmap.

Resist the temptation to assign thirty at once. The constraint was never the fixing; it's your attention at review time, and a wall of thirty PRs recreates the original problem with extra steps.

If it helps to make the habit stick, attach it to something that already recurs. On-call quiet hours work well: the person who just got paged past a papercut is the person best placed to spec it, and the fix lands before the annoyance fades.

Closing a ticket is also progress

Be honest about what tightening reveals. Some tail tickets are stale: the feature was rewritten, or the customer who reported it churned two years ago. When ten minutes with an old ticket turns up nothing left to fix, close it and say why. An agent can't fix a bug in code that no longer exists, and neither could a person. The goal is a backlog where everything listed is real, not a backlog of zero; the tail stops being the place where known problems go to be ignored.

Pick three tickets from the bottom of your backlog this week, tighten them, and hand them over. You can start for free, or read the docs to connect your tracker and repo.