Product backlog: mistakes to avoid (and grooming that works)
The product backlog is the most-used tool in an agile team, and often the worst-kept. Well maintained, it makes sprint planning quick and calm. Neglected, it becomes a list of four hundred tickets that nobody reads any more.
What is a product backlog?
The product backlog is the ordered list of all known work on the product: features, user stories, bug fixes, design changes, technical debt, customer requests, actions from retrospectives. It is the operational translation of the product roadmap: the roadmap says where you are going, the backlog says what needs doing to get there.
Its primary job is to feed sprint planning. All the work has to be in it, so that the team can make informed trade-offs with the product owner before each iteration. If it is not in the backlog, it should not be done.
What goes in it
- User stories, linked to epics on the roadmap.
- Bug fixes, rated by severity.
- Technical debt and infrastructure work.
- Discovery tasks: interviews, prototypes, data analysis.
- Retrospective actions, so that improvements do not stay good intentions.
The top of the backlog is detailed and ready to commit to. The bottom can stay rough. The further away an item is, the less writing effort it deserves.
How to prioritize
The product owner orders the backlog by value, weighing several criteria:
- Value for the user and for the business.
- Alignment with strategic goals and the hypotheses to validate.
- Feedback from users and from sales teams.
- Risk: whatever removes the most uncertainty often goes first.
- Effort and the team’s real capacity.
Scoring grids exist to formalize these criteria. They help make a discussion more objective, as long as they do not become a calculation that replaces judgement. A priority should be explainable in one sentence.
A triage routine for incoming requests
Most backlogs do not decay during grooming. They decay at the door: every request goes in as is, with no decision attached. Triage solves this. It is a short slot, separate from grooming, where the product owner deals with everything that has arrived since last time.
Every new item must leave triage with one of these five decisions:
| Decision | When | What happens |
|---|---|---|
| Act now | Blocking bug, security flaw, contractual commitment | Goes into the current sprint; the team is told |
| Order | Can be linked to a roadmap initiative | Placed in the backlog, in its rightful position, with its link |
| Merge | Duplicate or variant of an existing item | Added as context to the existing item; the requester is credited |
| Qualify | A real problem, but poorly understood | A precise question goes back to the requester, with a reply date |
| Decline | Unrelated to the goals or hypotheses | Closed, with a one-sentence explanation to the requester |
The last row is the hardest, and the most important. A declined request with a reason beats a ticket that sleeps for two years: the requester knows where things stand, and comes back with a better request. Allow fifteen minutes twice a week in a small team, and a daily slot when requests arrive from several sales teams or from many customers.
Backlog grooming that works
Grooming, also called refinement, is the regular session where the team reviews the backlog. Its purpose: make sure the top of the list is ready for the next sprint. This is the format I recommend:
- A short, regular session, every week or mid-sprint, rather than a monthly marathon.
- The product owner prepares: they arrive with the items to discuss already ordered and described.
- The team questions and splits: every item that is too big gets split, every vague item gets clarified.
- Rough estimates, to check that the top of the backlog fits within capacity.
- Clean-up: what no longer makes sense is deleted, duplicates are merged.
An item is ready when the team understands the problem, knows how to check it is done, and can deliver it within one sprint.
A session, step by step
A fictional example. A team of six building a booking tool for gyms. A forty-five-minute session mid-sprint, six items prepared by the product owner.
| Item | What happens | Outcome |
|---|---|---|
| “Pay in instalments” | The developers point out that the payment provider already supports it; the real topic is how the option is displayed. | Reduced to one interface story, ready |
| “Calendar redesign” | Too big. Split into three: week view, filter by coach, mobile display. | Week view ready, two others to refine |
| Bug: double booking | The tester describes the scenario; the cause is probably on the sync side. | Ready, with a written test criterion |
| “Accounting export” | Nobody knows which format the customer expects. | Sent back to qualification, question asked to the salesperson |
| Authentication library upgrade | The tech lead explains the security risk of postponing it again. | Moved to the top of the backlog |
| “Dark mode” | Requested once, eight months ago, linked to no initiative. | Deleted |
Result: three items ready, one split, one sent back to qualification, one deleted. That is a good session. A session where everything is “ready” without a single question is often one where the team did not really read the items.
The seven mistakes to avoid
- No regular grooming. The backlog goes stale, and sprint planning turns into a discovery session.
- Only adding what is visible. Interface items get through; technical debt and security wait until the incident.
- Prioritizing without criteria. The order reflects whoever pushed hardest last, and the team works on low-value topics.
- Leaving developers out. Items that are unfeasible or misunderstood get prioritized, and the team disengages.
- Keeping everything. A backlog of several hundred items is no longer a decision-making tool. Delete whatever has not moved in six months: if it matters, it will come back.
- Confusing backlog and roadmap. User stories do not explain direction. Without a roadmap above it, the backlog has no meaning.
- Not closing the loop. A delivered item is not done until you have checked it had the intended effect.
A ten-minute health check
Open your backlog and check these five points:
- What share of items is more than six months old? Above a third, the clean-up is overdue.
- How many items are linked to no epic and no hypothesis?
- Does the top of the list hold two to three sprints of ready items, not fewer and not many more?
- Are there technical debt and security items among the first twenty?
- Do the items delivered last quarter have a measured effect?
These thresholds are reference points, not standards. What matters is how they move from one month to the next.
Evolving the backlog over time
The backlog evolves with the product. Items that were relevant at the start stop being so after customer feedback or a shift in the market. As it works through tickets, the team records what it did, what worked and what did not; that information feeds the retrospective and the following sprints.
In a tool like Asana, one backlog project per team, linked to the roadmap project, works well. I describe this setup in building an agile roadmap in Asana.
Small team or large organization
A single team keeps a single backlog, and the product owner does the triage. When several teams work on the same product, keep one backlog per team, but a single front door for outside requests. Otherwise, sales quickly learn to drop the same request with whichever team is most accommodating. Dependencies between teams are handled in the agile roadmap, not in the backlogs.
In hindsight
Rereading this article written in 2022, I would not take anything essential out. The backlog is still the most used and worst kept tool. But three things have shifted in my practice.
What I would keep
Short, regular grooming, and deleting dormant items without regret. At Dotworld, where we shipped four SaaS products in six months, that pace would not have held with cluttered backlogs: a short backlog is a backlog people read.
What I would nuance
I underestimated triage at the door. I described grooming as the moment you clean up; I now think most of it happens earlier, when a request comes in. Hence the triage routine above, which I would not have written in 2022.
I would also nuance the rule “if it is not in the backlog, it should not be done”. It still holds for the product team’s work. But part of the work on an AI system, such as labelling examples or updating business content, is done by teams outside the product. It must be visible, not necessarily in the same backlog.
What AI assistants have changed
AI assistants are effective at the thankless backlog chores: spotting duplicates, grouping similar requests, proposing a first breakdown of an epic, rewording a vague user story. They make triage faster. Use them to prepare grooming, not to replace it: the team’s discussion is what creates shared understanding.
One caution: an assistant rewording a user story can add a criterion nobody asked for, with great confidence. Check every rewrite against the original request. The time saved should be measured with that review included, as I recommend in measuring the time AI actually saves.
Frequently asked questions
Who owns the product backlog?
The product owner, or the product manager depending on the organization. They decide its order and answer for it, but the whole team can propose items and takes part in refining it.
What is the difference between backlog grooming and sprint planning?
Grooming prepares: it clarifies, splits and orders upcoming items. Sprint planning commits: from the ready items, the team chooses what it will deliver during the iteration.
How many items should a backlog contain?
There is no ideal number, but two to three sprints’ worth of ready items at the top of the list is enough. Beyond that, the detail goes stale before it is used.
What is the difference between triage and grooming?
Triage decides the fate of each new request: act on it, order it, merge it, qualify it or decline it. Grooming prepares, with the team, the items already kept for the next sprints.
Where does AI fit in?
For an AI system in production, the backlog changes in nature. It contains items you do not see in a conventional product: categories of errors to fix, new business terms to add, edge cases reported by frontline teams, quality thresholds to monitor. These items come straight from measurement, as I explain in measuring an AI support assistant. An AI system without an improvement backlog fed from the field degrades silently.
The triage routine applies as is: an error that exposes the company is acted on now, a recurring category of errors gets ordered, an isolated case gets qualified. The improvement backlog is also what separates a system in production from a POC left as it was, the subject of from AI POC to production.