Backlog Management for One Human and Several Artificial Interns

I have started, and abandoned, more backlog systems than I have finished projects. The boards, the apps, the elaborately tagged note vaults. Each one worked for about a week, which is exactly as long as it took for opening it to become a task in its own right.

This is not a discipline problem, although it is comforting to pretend it is. It is a design problem. A backlog you have to remember to open is a backlog that depends on the one resource that is already overcommitted: my attention on a busy morning. And the situation is worse now, because the work is spread across many repositories with several agents touching them, so “what is actually going on across everything” is a question I can no longer answer from memory.

The backlog tool I kept not opening

The failure mode is always the same. The tool sits in a tab or an app. Using it requires me to decide to look, then look, then interpret. On a good morning I do all three. On a normal morning I skip straight to whatever feels most urgent, which is rarely what is most important, and the carefully maintained backlog quietly desyncs from reality. Within two weeks it is a museum of intentions and I am back to working from my own anxiety.

The thing I needed was not a better tool to open. It was for the relevant slice of the backlog to come to me, without my having to ask.

A brief that comes to me

So the backlog stopped being a place I visit and became a brief that is generated for me. Each day, a small deterministic script reads the state of the projects and produces a short brief: the top few things that actually want attention, anything that has gone stale, and whatever is blocked.

The word that matters there is deterministic. The brief is not an agent musing about my priorities. It is a fixed function over the visible state of the repositories: recent activity, age of last update, declared blockers. Same inputs, same brief. It does not get creative, and it does not get moody, which means I can trust it the way I trust a thermometer rather than the way I trust a colleague’s hunch.

The nudge is the feature

The part I expected to be a footnote turned out to be the point. Alongside the brief is a nudge: when a project has drifted, when the working context and the recorded state have diverged past a threshold, the system tells me to resync before carrying on.

The threshold is deliberately crude: three commits, or two days, whichever comes first. There is no machine learning in it. There does not need to be. The value is not a clever prediction of when context has drifted. The value is that something other than my memory is keeping count, so the resync happens on a schedule instead of happening the morning I finally notice everything is out of date.

The unglamorous nudge is the feature. Remembering to check is the thing I am worst at, so I gave it to a counter.

Boring beats clever

There is a more impressive version of this. An agent that triages the backlog, reprioritises, opens and closes tasks, maybe nags me in natural language. I built the boring version instead, and the boringness is doing real work. Because the brief never changes state and never improvises, I never have to wonder whether it quietly reorganised something while I was not looking. It earns trust by being predictable, which is a quality agents are not famous for.

It is validated in the narrow sense that matters: it runs every day, it has a test suite, and it has caught drift I would have missed. It is not validated as a universal answer to anyone else’s backlog. The thresholds are tuned to one person working across a handful of repositories. If you have a team, or twenty projects, the numbers are wrong and the shape might still be right. The shape is the part worth stealing: make the backlog come to you, keep it read-only, and let something other than your memory count the drift.