Why nobody updates the project board, and what to do about it

Ten minutes before the Thursday call, someone opens the board and starts dragging cards. Two of them merged last week. One has sat in In Progress since the twelfth and everybody knows it was abandoned. By the time the call starts the board is true again, and it stays true for about a day.

The standard answer to why nobody updates the project board is a behaviour answer. Appoint a champion. Lead by example. Make it part of standup. That advice was written for an organisation with a hundred engineers and somebody whose job includes noticing. On a team of five everyone is already the champion and the board is still wrong.

It is not a discipline problem. You have asked five busy people to maintain a second copy of something that already exists elsewhere.

The case for updating the ticket, made properly

First, the honest version: status updates are not pure waste. In a 2023 Hacker News thread on -10x engineering, rlpb defends the interruption directly — never updating a ticket until the problem is fixed "might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved" (news.ycombinator.com).

The update that feels most pointless to write is often the one carrying information. lelanthran notes that recording a failed day chasing a bug feels like "a worthless ticket update, but from the client's PoV, this is valuable info - it means that it hasn't dropped off our radar" (news.ycombinator.com).

Both are right, and neither is describing a status field. They are describing prose — a sentence another human could not have derived. No automation will produce that. The status column is a different object, and the two get conflated constantly.

Why nobody updates the project board

A status field is a claim about the world. For most software work an authoritative version of that claim already exists, written by the work itself.

Somebody cut a branch. Commits landed on it. A pull request opened. A reviewer approved it. It merged. Each of those is a timestamped event recorded in a system nobody has to be reminded to use, because using it is the work. Moving a card from To Do to In Progress is a second, manual, lower-fidelity write of a fact git already holds.

Duplicate writes drift. That is not a moral failing, it is what duplicate writes do. Kanban Tool's post-mortem of failed implementations puts it plainly: "For as long as the board is not kept up to date, anything that you do, and is based on the board information will be based on untrue information" (kanbantool.com).

What makes it vicious is the rate. Drift is proportional to how much is happening, and the weeks with three things in flight, an incident and a deadline are exactly the weeks nobody stops to retype what they are doing. The board is least accurate when someone most needs to read it. Every other record you keep gets more complete under pressure. This one gets less.

An Ask HN post from a manager of ten engineers shows the mechanism whole: "no one keeps their tasks updated and my PM struggles to assess project progress. I become the broker between PM and my team" (news.ycombinator.com). The reply that lands is not a habit fix. It is calrain telling him to go and find out "why they don't have time to update tasks and why they don't see it as a priority" (news.ycombinator.com).

Four signs it has already happened to you

1. The board is only touched before a meeting. If board activity has a weekly rhythm and the work does not, you are maintaining a presentation.
2. In Progress contains things that finished last week. Forward transitions happen sometimes. Closing ones almost never do: work finishing is the moment attention has already moved.
3. Somebody keeps a private list. A notes file, a pinned message, a whiteboard. It exists because someone who needed an accurate picture could not get one here.
4. People ask a person rather than the board. The terminal sign. The board has been demoted from system of record to a thing you tidy, and the real state lives in one or two heads.

What actually fixes it

Stop asking a human to author a fact a machine already has. That is the whole principle. turtleyacht, replying in that Ask HN thread, gets there in two sentences: "The code is the work. The pull request is the workface" (news.ycombinator.com).

In practice: cut the states a person must type down to the ones no system can observe. Blocked on a decision, dropped, deprioritised, waiting on a customer are judgements a human has to make. To Do, In Progress, In Review and Done, for anything with a branch attached, are observations — and something already observed them.

This is the assumption Kevta is built on. You copy a ready-made branch name off the issue — feature/MS-42-refactor-router — and when the pull request opens Kevta matches it back by issue key from the branch, title, body or commit messages. No linking step, no magic word. Rules then move the issue: a new board seeds eight and five ship on — branch pushed to In Progress (only when the issue is currently To Do), pull request opened or marked ready to In Review, approved to Ready for QA, merged to Done. Three ship deliberately off, all reverse transitions, because a board that drags finished work backwards is worse than a stale one. Setup is in the board docs; which git events deserve binding to a state is its own post.

Where this does not help

It only covers work with code attached, and plenty does not. A design exploration, a spike that ends in a decision, six weeks waiting on someone else's legal review — git has no opinion about any of them, and those cards still need a person. It also only works if people use the branch names, a smaller ask than a daily ritual but not nothing.

It does not produce the narrative update lelanthran was defending. Nothing does. What it buys is narrower: when someone writes a comment, it is because they had something to say rather than because the column was lying. Same ambition as what a five-person team needs from issue tracking — fewer obligations, and a board you can believe on the Thursday you did not tidy it.

Kevta is in beta. If a tracker that updates itself off your git history is what you want, join the waitlist for an early invite, a founding-member price at launch and a direct line to shape what we build next.