From One Session to a Team Playbook

A teammate’s queue had 22 tickets on it. Five were small and ready to pull. The other 17 had been sitting in Inbox long enough that nobody remembered why they were still there.

That was the whole problem, not a mystery, just a queue nobody had looked at in a while. Tickets pile up in a shared board the same way email piles up in an inbox: everything arrives at the same priority, and priority stops meaning anything. A teammate had 22 items assigned to him and no way to tell, at a glance, which ones he could start on right now and which ones were waiting on someone else, or waiting on nothing at all.

Sorting the pile

I went through his board ticket by ticket. Five of them were small, ready, no blockers, nothing pending from anyone else. Those got moved to the top tier so he’d pull them in order without having to re-read the whole list every morning. The other 17 were a different problem: old, stale, no recent activity, no clear reason they were still open. Those got left at the bottom, flagged for cancellation, but the decision to actually cancel them belongs to the business owner, not to me. I don’t get to unilaterally close out someone else’s backlog.

Then I built him a ranked pull list, a single ticket that says “here’s what to work on and in what order,” pulled from both his plate and mine so he wasn’t juggling two separate views of the same work.

The part that made it worth repeating

Here’s where it stopped being a one-off. Two other people on the team run the same kind of queue, and their boards have the same problem: everything flat, nothing tiered, old tickets mixed in with fresh ones. I’d just done the sorting work by hand for one person. Instead of doing it by hand three more times, I wrote down exactly what I’d done, the tiering rule, the “what counts as stale,” the pull-list format, as a saved command: /queue groom. Anyone can run it against their own queue and get the same treatment: top tier for small and ready, bottom for stale-and-flag, a ranked list to work from.

The point isn’t that a script sorts tickets. Sorting tickets is fast either way. The point is that the first time I did it, the process lived entirely in my head, in the specific choices I made about this one person’s queue on this one night. If someone had asked me the next week how I decided what counted as stale, I’d have had to reconstruct it. Writing it down as a playbook meant the second and third time it ran, it ran the same way, with the same rules, whether I was the one running it or someone else was.

That’s a small thing, but it’s the difference between fixing a queue and fixing how we handle queues. The first helps one person for one week. The second means the next teammate whose board gets cluttered doesn’t wait for me to notice and do it by hand. It also means if I disagree with my own judgment call from a month ago, there’s an actual document to argue with instead of a memory.

What I didn’t do

I didn’t cancel the 17 stale tickets myself, even though the playbook flags them clearly enough that I could have. Somebody owns those tickets, and closing work that isn’t mine to close is exactly the kind of decision that needs a person, not a rule I wrote for myself at 1 AM. The playbook sorts and flags. It doesn’t delete. That boundary is part of what got written down too, not just the tiering logic but where the automation stops and a human has to say yes.

dxdev LESSON · paste into your AI coding agent
LESSON: Turn A One-Off Cleanup Into A Written Playbook Before Repeating It By Hand
SOURCE: dxdev.com/blog/2026-09-09_queue-groom-playbook-scales
WHAT HAPPENED: A teammate's board had 22 tickets sitting at the same flat priority. Going through them by hand, five were small and ready with no blockers, so they got moved to a top tier and combined with the writer's own tickets into a single ranked pull list. The other 17 were stale with no recent activity, so they were flagged for cancellation and left at the bottom, since closing them wasn't the writer's call to make. Two other teammates ran queues with the same flat, untiered problem, so instead of manually repeating the sort for each of them, the tiering rule, the definition of stale, and the pull-list format were written down as a saved command, `/queue groom`.
THE RULE: When a manual fix works and you notice the same problem exists elsewhere, write down the exact rules you used as a reusable process before repeating the manual work, and keep any decision that isn't yours to make, like canceling someone else's ticket, outside the automation.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does the process document a specific, checkable definition of what counts as ready versus stale, rather than leaving it to judgment each time?
      2. Can someone other than the original author run the process and get the same tiering result?
      3. Does the automation stop short of taking actions that belong to a different owner, such as canceling or closing someone else's work?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.