Our Jira Backlog Had 847 Tickets. An AI Agent Cut It to 312.

Tomas opened his team's Jira backlog on a Tuesday morning and counted. Eight hundred forty-seven tickets. He'd been the product manager for this team for two years, and the backlog had been growing at a rate of about 15 net tickets per week -- new issues filed minus issues completed. At that rate, even if the team stopped all new work and just ground through the backlog, they'd need eight months. And the team wasn't going to stop all new work. The backlog was a landfill, and every sprint planning session was an archaeological dig.

He knew what was in there. Everybody knows what's in a bloated backlog. Feature requests from customers who churned 18 months ago. Bug reports for a UI that was redesigned in Q3. Duplicate tickets filed by different people who didn't search first. "Tech debt" cards that were really just complaints, with no actionable scope. Enhancement ideas from a brainstorm session that nobody remembers. Tickets that were valid once but are now obsolete because the product direction changed.

The problem isn't identifying these categories. Any PM can look at a ticket and say "this is stale" or "this is a duplicate." The problem is doing it 847 times.

Why Backlogs Grow Out of Control

Every team I've worked with has the same pattern. Backlogs don't grow because people are careless. They grow because creating a ticket is cheap and closing one has a social cost.

Filing a ticket takes 30 seconds. You see a bug, you file it. A customer asks for a feature, you file it. An engineer notices some tech debt, they file it. The barrier to entry is effectively zero, which is by design -- you want people capturing work that needs to be done.

Closing a ticket -- really closing it, not just letting it age -- takes effort and sometimes a conversation. Close a customer's feature request and you might need to tell them it's not happening. Close an engineer's tech debt ticket and you might get pushback. Close a stale bug and three weeks later someone reopens it because the bug resurfaced. So people don't close tickets. They leave them open. "We'll get to it eventually" is the polite fiction that keeps backlogs growing.

Sprint planning reinforces the pattern. Teams pull from the top of the backlog, work on what's prioritized, and ignore the rest. The bottom of the backlog becomes a graveyard that nobody visits. Every quarter someone says "we should really clean up the backlog" and it gets added to the backlog.

Tomas had tried the manual grooming approach twice. The first time, he blocked off a Friday afternoon and got through 120 tickets before his eyes glazed over. The second time, he brought two engineers into a grooming session and they got through 80 tickets in an hour -- faster, but painful. The engineers hated it. "I'd rather write code than read year-old tickets about features we're never going to build," one of them said. Fair point.

The Anatomy of a Bloated Backlog

Before Tomas ran the agent, he wanted to understand what he was dealing with. He exported the backlog to a spreadsheet and did a rough categorization of the first 200 tickets:

• Stale tickets (no updates in 6+ months, reporter no longer at the company or no longer a customer): about 35% of the backlog
• Duplicates (same issue filed by different people, or the same issue filed twice because the reporter forgot they'd already filed it): about 15%
• Obsolete tickets (valid when filed, but the product has changed and the issue no longer applies): about 12%
• Vague tickets (no clear acceptance criteria, no reproduction steps for bugs, just a title and maybe one sentence of description): about 10%
• Legitimate but low-priority (real work that could be done, but has been deprioritized for over a year): about 20%
• Actually relevant (should be in the active backlog, just buried): about 8%

That last category is the one that hurts. There were tickets in the backlog that the team actually should have been working on -- they'd just been buried under 700 other tickets and nobody could find them.

What the Agent Did

The backlog grooming agent processed all 847 tickets over about 40 minutes. For each ticket, it read the title, description, comments, linked issues, reporter, assignee, creation date, last update date, and the issue's change history. Then it categorized the ticket and recommended an action.

The categories mapped roughly to what Tomas had seen in his manual sample, but with more precision:

Recommended Close (367 tickets): These fell into sub-categories. Stale tickets with no activity in 9+ months and no linked work. Duplicates -- the agent found 73 sets of duplicate tickets, some with 3 or 4 copies of the same issue. Obsolete tickets referencing features, endpoints, or UI components that no longer exist. The agent added a comment to each one explaining why it recommended closure, which made Tomas's review faster because he could just scan the reasoning instead of re-reading the whole ticket.

Recommended Merge (94 tickets, into 38 parent issues): Tickets that weren't exact duplicates but were close enough to consolidate. "Add dark mode to settings page" and "Support dark theme across the app" and "User preference for light/dark UI" -- three tickets that should be one epic. The agent identified the most complete ticket in each cluster and recommended merging the others into it.

Recommended Update (74 tickets): Tickets that were still relevant but needed refreshing. Bug reports where the reproduction steps referenced an old UI flow. Feature requests where the original context had changed. The agent flagged what was outdated in each one so Tomas could update them or ask the original reporter to revise.

No Action Needed (312 tickets): The surviving backlog. These were either actively being worked on, recently triaged, or still relevant and properly scoped.

The Review Process

Tomas didn't blindly accept every recommendation. He spent about three hours reviewing the agent's output, which is a lot less than the 30+ hours it would have taken to review 847 tickets manually.

His review process was simple. For the "Recommended Close" pile, he spot-checked about 50 tickets (roughly 15%) and agreed with the recommendation on 46 of them. The 4 he disagreed on were all borderline cases -- tickets that were technically stale but related to a project the team was planning to restart next quarter. He moved those to the "No Action" pile and closed the rest.

For the "Recommended Merge" pile, he reviewed every cluster. The agent was right on about 80% of them. The wrong 20% were cases where tickets looked similar on the surface but addressed different aspects of the same problem -- "improve search performance" and "fix search relevance" aren't the same work even though they both involve search. He split those back out.

For the "Recommended Update" pile, he forwarded each ticket to the original reporter (if still at the company) or the relevant team lead with a note: "This ticket needs a refresh. Still relevant? If so, please update the description. If not, let's close it."

The whole process -- agent run plus human review -- took about four hours. The result was a backlog of 312 tickets that were current, properly scoped, and actually findable.

What Changed After the Cleanup

The immediate effect was that sprint planning got faster. Before, the team spent the first 20 minutes of every planning session scrolling past irrelevant tickets to find the ones that mattered. After, the backlog was readable. You could scan the top 30 tickets and understand the team's priorities without excavation.

The second effect was less obvious but more lasting. The team started trusting the backlog again. Before the cleanup, engineers had stopped checking the backlog for context because it was too noisy. "Is there already a ticket for this?" was a question nobody bothered asking because the answer required searching through 847 tickets and nobody had time. After the cleanup, searching actually worked. Duplicate filing dropped because people could find existing tickets.

Tomas now runs the agent monthly. The backlog hovers between 280 and 350 tickets. The monthly run catches new duplicates, flags tickets that have gone stale since the last run, and surfaces buried tickets that should be prioritized. It takes about 30 minutes of agent processing and an hour of Tomas's review. That's a fraction of the recurring grooming ceremonies the team used to run.

The Stuff the Agent Can't Do

The agent is good at identifying what's stale, what's duplicated, and what's obsolete. It's not good at determining strategic priority. "Should we build this feature?" is a product decision that depends on roadmap, revenue, customer conversations, and competitive pressure. The agent doesn't have that context and doesn't pretend to.

It also struggles with tickets that are intentionally vague -- early-stage ideas that are more like notes than actionable work items. Tomas's team uses a "Discovery" issue type for these, and he excludes them from the agent's grooming runs. Trying to groom ideation tickets based on completeness criteria misses the point.

And the agent's duplicate detection, while much better than keyword matching, isn't perfect. It occasionally clusters tickets that share vocabulary but address different problems. Human review of the merge recommendations isn't optional -- it's where the PM adds the product judgment that the agent can't.

Why Use an Agent For This

Manual backlog grooming doesn't scale. A PM can review maybe 30-40 tickets per hour with full attention, which means a backlog of 500+ tickets is a multi-day project that nobody wants to do. And because nobody wants to do it, backlogs grow until they're so large that the grooming effort feels impossible, which means they keep growing. It's a vicious cycle.

An AI agent breaks the cycle by handling the mechanical parts of grooming -- reading tickets, identifying staleness, detecting duplicates, flagging obsolescence -- at a speed that makes the problem manageable. The PM still makes the final call. They just make it on a curated list of recommendations instead of an 847-ticket wall of noise.

The Jira tools the agent uses are straightforward: Search Issues to pull the backlog, Get Issue for full ticket details, Add Comment to explain recommendations, and Transition Issue to close the ones the PM approves. The intelligence isn't in the API calls. It's in knowing which tickets to close and why.

Try These Agents

• Jira Backlog Grooming Agent -- Identify stale, duplicate, and irrelevant backlog issues with recommended actions
• Jira Ticket Triage Agent -- Auto-triage incoming issues to prevent backlog bloat at the source
• Jira Sprint Status Reporter -- Generate narrative sprint summaries from Jira sprint data
• Jira Standup Report Generator -- Daily standup summaries pulled from Jira instead of manual self-reports