Done is a column, not a fact

I keep work in two trackers. One is a hosted product with epics, iterations and a burndown chart I have never once opened. The other is a pile of issues sitting next to the code. I use both of them as a giant todo list, so that I do not lose sight of the work.

For a while I assumed that was a discipline problem, and that a better-run version of me would be using the rest of it. I have stopped thinking that. The estimating, the velocity, the sprint as a container of committed work: all of it was built for a constraint I no longer have. What is left, and the only part I reach for every day, is retention. It remembers. That is worth a great deal, and it is not what the product is sold on.

But a todo list cannot answer the two questions I now care about most:

• Which of these is ready for an agent to pick up without me in the room?
• Which of these came back provably finished, rather than marked finished?

What these tools actually record

Every tool in the category models work as state a human declares. Someone moves a card to Done, and the system records the assertion with a timestamp and a name against it. Nothing stands behind it except the person who moved it.

That was entirely adequate when a human did the work, because then their judgment was the evidence. They wrote the thing, they knew what they had done, and the status was a fair summary of something they were holding in their head.

That is not where I am. An agent produces more in an afternoon than I can read carefully, and the tracker still takes my word for it.

Here is the uncomfortable version. I have marked work done that I read line by line. I have marked work done that I skimmed. And I have marked work done where I checked that the gates were green and trusted them, which is a different claim altogether. The tracker recorded all three identically. Nothing in it knows the difference, and in six months neither will I.

Done is a column. It is not a fact.

What a tool designed for this would hold

Not a specification, and I am not equally confident about all of it. But these are the absences I notice every week.

The criterion and the thing that proves it, bound together. Not acceptance criteria as a paragraph of prose in a description field, but each criterion pointing at the check that demonstrates it, the run that executed that check, and the commit it ran against. Store that and done stops being a column: it is computed, and it can come back false. It also makes the opposite visible: criteria with nothing behind them at all. That is a number; it should be zero when something ships, and today nobody can even count it.

Where a piece of work is allowed to touch. An agent's reach is the whole tree, so two items that look independent on a board routinely are not. If each item declared its write scope, overlap between everything in flight becomes something a machine finds before the work starts, instead of something I find in a merge conflict or, worse, three weeks later in behavior nobody meant to change.

When one item spawns another, whether the problem was found or introduced. Working on one thing produces more things. Some are problems that were always there and the agent surfaced, which is good news arriving in the shape of bad news. Others the agent created, usually because nothing told it what already existed. Those are two different diseases with two different cures, and every tool I know lets me link the items while recording nothing about which kind it was. Whoever reviews the spawned item should be the one who marks it, rather than whoever created it, and the month's mix of the two is the whole report.

Who or what authored the change. Agents work under my credentials, so the record says I wrote it. That is not true in any useful sense, and it costs me the measurement I most want, which is how much rework attaches to work produced under different levels of human attention. The fix is not even difficult: give each agent lane an identity of its own and put the operator in the commit trailer. That it is this cheap and still almost nobody does it is the part worth sitting with, because everything downstream, review load and rework and defect attribution, is then reported as though a person wrote all of it.

And one field I would delete: the estimate. A cap on how big an item may be, enforced when it is created, does that job better than a number argued over in a meeting. If a thing needs more than one round of proof, it is two things.

The rule any of this has to obey

Every field a tool asks a person to fill in has to pay them back in the same sitting.

Ask me for a write scope, and warn me about a collision now. Ask me whether a problem was found or introduced, and show me this month's mix now. Ask me for a criterion, and hand me the check that will prove it.

Discipline that only pays off in a report somebody reads in January does not get entered, and I include myself in that. A measurement system whose inputs quietly rot is worse than no measurement at all, because it produces numbers that look like evidence.

Nobody needs another tracker

I want to be clear about what I am not arguing for. The graveyard of work-tracking tools is well populated. Switching costs for a team are brutal, history does not migrate cleanly, and executives keep looking at the place they already look. A new board that asks everyone to move in order to earn better numbers is not going to happen, and it does not need to.

Nearly all of this already exists somewhere. The repository knows what changed and when. The pipeline knows what ran and whether it passed. The tracker knows what was asked for and who was waiting on whom. What is missing is not another place to type things. It is the layer that binds a criterion to the run that proved it, and that can therefore answer the two questions at the top.

I am building that measuring layer, starting with my own work, so read the diagnosis knowing where it comes from. These notes are the reasoning behind it rather than advertising for it: the argument stands with or without a tool at the end, and the fields above are worth adding to whatever you already use even if I never ship a thing.

The part I have not settled

Whether the proof record belongs in a tool at all.

The alternative is that it lives in the repository, next to the code, as a committed file for each item. That version is more durable in every way that matters: it travels with the code, it survives the tool being replaced, it can be reviewed in a pull request like anything else, and it is readable without an account. It is also much harder to sell, and it asks more of the people using it.

I lean toward the file. I have also been wrong about that kind of call before, usually by preferring the version that appeals to someone who already thinks the way I do.

If you have tried either shape with a real team, I would like to hear which parts of it survived contact.