Remediating four thousand vague tickets
You measured the backlog and it is bad. Marching through it in order is the wrong answer. Here is a triage that finishes in weeks rather than never.
The instinct, when the backlog audit comes back ugly, is to schedule a cleanup. Someone proposes a backlog grooming initiative. A spreadsheet appears. Two engineers and a product manager are assigned to work through the list, oldest first, rewriting acceptance criteria.
I have watched this exact plan several times and I have never seen it finish. It dies somewhere around ticket three hundred, usually in week three, when a real deadline arrives and the cleanup is the only thing on the board with no customer attached to it. What survives is a backlog with three hundred beautifully specified tickets, most of which will never be built, and thirty-seven hundred untouched ones, plus a team that now believes criteria remediation is a thing that gets started and abandoned.
The failure is not effort or discipline. It is that the plan treats four thousand tickets as four thousand units of equal value. They are not. The overwhelming majority of them will never be worked on, and you know it.
The first cut: most of it is not real
Before you rewrite a single criterion, ask a colder question. Which of these tickets is anyone ever going to build?
Run these filters. Each one is a query you can write in five minutes.
Untouched for more than a year. Not created a year ago: untouched. No comment, no field change, no link, no reference. A ticket that nobody has interacted with in twelve months is a note, not a plan.
Created by someone who has left. Ownerless intent is almost always dead intent. Somebody had a reason and the reason left with them.
In a component that no longer exists, or refers to a service you have decommissioned, or a customer who churned.
Duplicates and near-duplicates. Search for tickets sharing three or more significant title words. Long backlogs accumulate the same idea five times because nobody could find the original.
Below the line. If your team ships roughly forty tickets a month, everything beyond about the top three hundred is, arithmetically, more than six months out, and the odds that a six-month-old specification is still correct when it reaches the top are poor.
Bulk close them. Not delete: close, with a resolution like stale-bulk-2026-08 and a comment saying they can be reopened. This matters, because the objection you will get is “but what if we need it”, and closed-and-searchable answers that objection completely. In every backlog I have seen this run against, the reopen rate afterwards is tiny, and the tickets that do come back come back because someone actually wanted them, which is the correct filter.
Expect this cut to remove somewhere between half and three quarters of the list. The remediation problem you actually have is not four thousand tickets. It is closer to four hundred, and four hundred is a tractable number.
The second cut: remediate at the point of use
Here is the principle that makes the rest of this work. Do not remediate the backlog. Remediate the tickets as they enter the work.
A ticket’s criteria only need to be good at the moment someone is about to build it. Criteria written six months early are speculative, will be wrong by the time they are used, and cost the same to write as criteria written the day before. Writing them early is not investment, it is inventory, and inventory in a backlog decays.
So the operational change is to move the criteria bar into your definition of ready, at the sprint or intake boundary, and enforce it there. Nothing enters the sprint without criteria that clear the bar. The backlog behind that boundary can stay as messy as it likes, because messiness in tickets you are not building costs you nothing.
This one change fixes the problem permanently, on a rolling basis, at a cost of a few minutes per ticket that you were going to spend anyway during refinement. Everything else in this article is about the transition.
Do not remediate the backlog. Remediate tickets as they enter the work.
Criteria only need to be good at the moment someone is about to build. Written six months early they are speculative, wrong by the time they are used, and paid for twice. Move the bar into the definition of ready and enforce it at the intake boundary.
The third cut: the tier that gets real attention
Of the tickets that survive, three tiers, and only one of them gets craft.
Tier 1: next two sprints, plus anything touching money, auth, permissions, or data deletion. These get properly rewritten, by hand, with the failure cases specified. Somewhere between thirty and eighty tickets. This is a week of focused work for two people and it is the only part of the exercise with a hard quality bar.
Tier 2: the rest of the credible near-term backlog. These get a fast pass: convert prose to checkboxes, split conjunctions, delete ceremonial boxes, flag vibe words. Two minutes each, not twenty. The goal is not excellence, it is to remove the criteria that are actively misleading and get the format machine-readable.
Tier 3: everything else that survived the first cut. Leave it. Genuinely, leave it. It gets fixed when it gets pulled, under the definition-of-ready rule.
The mistake I see most often is applying Tier 1 effort to Tier 2 tickets because it feels irresponsible not to. It is not irresponsible. It is triage, and the alternative is not finishing.
What the fast pass actually looks like
Two minutes per ticket sounds impossible until you see how mechanical it is. Here are real transformations at that speed.
Prose to checkboxes. No new thinking, just re-shaping.
Before:
The admin should be able to export the user list and filter it by
signup date and plan.
After:
- [ ] Admin can export the user list as CSV
- [ ] Export respects the signup date filter currently applied
- [ ] Export respects the plan filter currently applied
- [ ] Non-admins get 403 and no file
Thirty seconds, and the last line came free because splitting the conjunction made the missing permission case obvious. This happens constantly.
Delete the ceremony.
Before:
- [ ] Code complete
- [ ] Unit tests written
- [ ] Peer reviewed
- [ ] Deployed to staging
- [ ] Works as expected
After:
(deleted, moved to the team's standing definition of done)
Five boxes that are identical on every ticket carry zero information per ticket. They belong in one place, in your workflow, not copy-pasted four thousand times where they dilute the boxes that actually mean something. Removing them is one of the highest-value bulk edits available and it can be done with a script.
Flag rather than fix. When a Tier 2 ticket has a criterion you cannot fix in two minutes because it needs a product decision, do not sit and think. Leave a marker:
- [ ] Pricing changes apply to existing subscribers ⚠ NEEDS DECISION:
immediately, at next renewal, or grandfathered? Blocks estimation.
That is a better artefact than either the original vagueness or twenty minutes of your guessing. It converts an invisible ambiguity into a visible question, addressed to the person who can answer it, and it means the ticket cannot silently enter a sprint half-understood.
Using drafting assistance without producing sludge
The obvious question in 2026 is why any of this is manual. Models are good at turning a prose ticket into a testable checklist, and tools exist that do this directly against your tracker, including flagging untestable language and drafting a checkbox version for a human to accept or edit.
Use it. With two rules.
Rule one: drafted criteria are a proposal, and a person accepts them. An unreviewed drafted checklist is a confident guess about what you meant, written in the format that signals verified. That is the exact laundering problem from earlier in this series, at scale. The draft saves you the typing, which is most of the cost, and it cannot save you the deciding.
Rule two: never auto-apply to Tier 1. Money, auth, permissions and deletion are where the specification carries the most weight and where a plausible-but-wrong criterion is most expensive. Draft assistance is fine as a starting point there, but a human writes the failure cases, because the failure cases are the part a model has the least evidence about. It does not know that your refunds are asynchronous or that your permission model has a legacy exception for the founding customer.
Where drafting genuinely shines is Tier 2 at bulk. Reformatting prose into checkboxes, splitting conjunctions, and flagging untestable words are exactly the mechanical transformations you want automated, and reviewing a proposed diff is far faster than authoring from scratch. A realistic Tier 2 pass with assistance is closer to thirty seconds a ticket than two minutes, which changes what is possible in a week.
Sequencing the whole thing
If I had to write the plan on one page:
Week 0. Score the backlog (an hour). Publish the number. Get explicit agreement that bulk closure is allowed.
Week 1. Run the stale filters. Bulk close with a reversible resolution. Announce it clearly with the reopen instructions, because the surprise is what generates objections, not the closure. Simultaneously change the ticket template: criteria field required, one prompt asking what happens when it fails, checkboxes as the default format.
Week 2. Introduce the definition-of-ready gate at sprint planning. This is the permanent fix and the sooner it starts, the less remediation you will ever need to do again. Expect the first two planning sessions to be uncomfortable and slow.
Weeks 2 to 3. Tier 1 rewrite. Two people, pairing, out loud. Pairing matters more than it sounds: the argument about what “paid” means is the actual work, and it does not happen when someone rewrites criteria alone at their desk.
Weeks 3 to 4. Tier 2 fast pass, assisted, reviewed.
Ongoing. Weekly score of newly created tickets. Nothing else tracked.
Four weeks, not four months, and the permanent behaviour change lands in week two rather than at the end.
Where this breaks down
Bulk closure is politically expensive and it is not always safe. Somewhere in those three thousand stale tickets is a compliance requirement, a promise made to a customer in a renewal negotiation, or a security finding that was logged and never scheduled. Closing it does not delete it, but it does remove it from every view anyone looks at, and “it was closed as stale in 2026” is a genuinely bad sentence to say in an audit. Before running the filters, exempt anything tagged security, compliance, legal, accessibility, or linked to a customer commitment, even if it is ancient. That exemption list costs ten minutes and it is the difference between a clean-up and an incident.
The definition-of-ready gate can become a bottleneck that people route around. If criteria authoring falls entirely on one product manager, the gate turns into a queue at that person’s desk, and the team’s response will be to push work in through side channels: bugs that are really features, tickets created mid-sprint, work done with no ticket at all. Then your board is worse than before and your metrics say it is better. A gate only works if the capacity to clear it is distributed, which usually means engineers writing criteria too, which is a cultural change some teams will resist hard.
Some of Tier 3 will get pulled without remediation and nobody will notice. The rolling model assumes the definition-of-ready gate always fires. In practice, urgent work jumps queues, and the tickets that jump queues are exactly the ones with the highest stakes and the least specification. That is not a hypothetical failure, it is the normal one, and the honest mitigation is a hard rule that anything touching the Tier 1 categories cannot skip the gate regardless of urgency.
And the whole exercise has an uncomfortable premise: that the backlog should exist at all. Four thousand tickets is not a backlog, it is a landfill with a search function. Some very effective teams keep a list of forty things and delete anything that falls off the bottom, and they would find this entire article to be an elaborate treatment of a self-inflicted problem. They have a point. If you are doing this remediation more than once, the problem is not criteria quality, it is that you are storing far more intent than you can ever act on, and the correct fix is upstream of anything written here.
The takeaway
Do not march through the backlog. Delete most of it, gate the entrance, and rewrite only what you are about to build.
Concretely: bulk close the stale (with an exemption list), require criteria at sprint entry, hand-craft the thirty to eighty tickets that are near-term or high-stakes, do a fast mechanical pass on the credible remainder, and leave the rest alone forever. Four weeks, with the permanent change landing in week two.
The reason this works is that criteria are perishable. They are worth writing when they are about to be used and close to worthless when written six months ahead, so a process that writes them just in time will always beat one that tries to write them all.
The next piece moves upstream of the ticket entirely: how a product requirement becomes an entity model and then an execution plan, mechanically, and what has to be true for that chain to hold together without a human retyping it at every step.