Backlog Grooming That Doesn't Suck

Your backlog has 247 tickets. Thirty-two are labeled "someday." Fifteen have no assignee. Eight reference features that were canceled six months ago. And there's still that ticket from 2024 titled "Investigate weird thing in prod" with no description.

If this sounds familiar, you don't have a backlog. You have a graveyard.

Backlog grooming (or "refinement" if you prefer the official Scrum term) has become the meeting everyone dreads. An hour of scrolling through Jira, arguing about story points, and pretending tickets from Q2 2025 are still relevant. Meanwhile, your team is mentally checked out, wondering why they aren't writing code instead.

The reality? Most teams treat their backlog like a storage unit—shove everything in and deal with it "later." But that "later" never comes, and the backlog becomes a source of anxiety rather than clarity.

Here's how to fix it without adding another weekly ceremony to your already packed calendar.

The Core Problem: Zombie Tickets

The biggest issue isn't the size of your backlog—it's the zombie tickets. These are items that look alive but are functionally dead:

• Stories with no acceptance criteria
• Bugs filed before your current architecture existed
• Feature requests from stakeholders who left the company
• "Nice-to-have" items that will never be prioritized

These zombies create cognitive load. Every time someone scans the backlog, they have to process whether each ticket is still valid. That mental overhead compounds across the team, sprint after sprint.

The 3-Category System

Stop trying to groom everything. Instead, ruthlessly categorize your backlog into three buckets:

1. Ready to Build (Max 20 Items)

These are your next 2-3 sprints. Fully groomed, with acceptance criteria, dependencies identified, and rough estimates. This is the only section that needs regular attention.

2. Discovery/Research (Max 15 Items)

Ideas that need more investigation before they're ready to build. These don't need story points—they need questions answered. Revisit this section once every two weeks.

3. The Archive (Everything Else)

Here's the controversial part: Close everything else. Not "backlog for later," not "low priority." Close them. Mark them "Won't Do" or move them to a separate "Deep Archive" project.

If someone complains their idea was closed, tell them to reopen it when it becomes a priority. Spoiler: They rarely do, because it was never important.

Real-World Example: The Archive Experiment

Last year, I worked with a startup whose backlog had 400+ tickets spanning three years. The PM was spending 3 hours every week grooming, and the team still couldn't find what mattered.

We ran an experiment: Archive anything not touched in 6 months. The team panicked. "What if we need those ideas?" I promised we'd track reopened tickets.

Result: We archived 320 tickets. Over the next three months, exactly four were reopened. Four. The rest? Never missed.

The team's velocity didn't change, but their stress dropped. They stopped wasting mental energy on tickets that would never ship.

The 15-Minute Grooming Habit

Instead of a weekly 60-minute grooming meeting, try this:

• 5 minutes at the end of standup, twice a week: The PM quickly reviews the "Ready to Build" section with the team. "This ticket needs acceptance criteria. Sarah, can you clarify this dependency?"
• Async for everything else: Use Slack/Teams. "Hey @dev, can you estimate this ticket when you have 10 minutes?"

The key: Grooming is continuous, not an event. You don't schedule time to organize your desk once a week—you tidy as you go.

What to Avoid

• The "We Might Need This Someday" Trap: If it's not on the roadmap for the next quarter, close it. You can always reopen later if priorities change.
• Over-Detailing Future Work: Don't spend 30 minutes writing acceptance criteria for a ticket that won't be worked on for 8 weeks. Requirements will change by then anyway.
• Democratic Grooming: Not every ticket needs team consensus. The PM should handle most grooming solo. Bring the team in only for technical unknowns or estimation.

Tactical Tips for Remote Teams

If you're distributed across timezones, grooming meetings are even more painful. Here's what works:

• Use Loom or Slack Video: The PM records a 5-minute walkthrough of next sprint's tickets, team responds async with questions or estimates.
• Label Your Zombies: Create a "Needs Decision" label. When you spot a zombie during grooming, tag it. Review all "Needs Decision" tickets once a month and close them.
• Automate the Obvious: Jira automation rules can auto-close tickets with no activity in 90 days or move them to an archive status. Set it and forget it.

The Grooming Anti-Pattern

The worst backlog grooming session I ever attended:

• 90 minutes long
• 12 people on the call
• We "groomed" 45 tickets
• None of them would be worked on for at least 8 weeks
• Three team members were visibly coding during the call

What should have happened: The PM grooms solo, flags 3-4 tickets with technical unknowns, and brings those to a 15-minute focused discussion with the relevant devs. Everyone else gets their time back.

Takeaways

• Keep "Ready to Build" under 20 tickets. Archive or close everything else.
• Groom continuously in small bursts, not in marathon weekly meetings.
• Zombie tickets create cognitive load—kill them ruthlessly.
• If a ticket hasn't been touched in 6 months, close it. You can reopen if needed (you won't).
• Not every ticket needs team consensus. Trust your PM to handle 80% of grooming solo.

Resources

• Atlassian: Backlog Refinement Best Practices
• Jira Automation Rules for Backlog Cleanup
• Monday.com: Agile Ceremonies Guide