When your board becomes fiction, in weeks not quarters
Boards have always drifted from reality. What changed is the rate. A board that used to take a quarter to become misleading now manages it in about eleven days.
A delivery manager pulls the sprint board on a Thursday morning to prepare for a stakeholder call. Fourteen tickets in progress, three in review, two done. It looks like a team that is behind, so she writes an honest note saying the sprint is at risk and one of the two committed features will probably slip.
The call goes fine. The stakeholder reprioritises, pulls a designer off something else to help unblock, and pushes a customer conversation back two weeks.
The feature had been merged and deployed the previous Friday. Six days earlier. Three of the fourteen “in progress” tickets were finished, one was abandoned when the approach changed, and two of them described work that another team had already done in a different repository. The two “done” tickets were done in the sense that they had been closed, but one of them had a follow-up pull request merged after closure that changed the behaviour materially.
Nobody lied. Nobody was even negligent. The delivery manager read the system of record correctly and reported what it said. The system of record was simply a work of fiction, and it had become one over about eleven days.
Board drift is not new, the rate is
Every experienced engineering leader has a story about a board that had gone stale, and most of them have a story about the effort to fix it: the ticket hygiene push, the “everyone update your tickets before standup” initiative, the two weeks where it worked and the slow return to baseline.
So the instinct is to file this under a known problem. Boards drift. We know. We have a process for it.
The reason that instinct fails now is that every remediation for board drift ever devised assumed a particular ratio: that the rate at which reality changes is slow enough for human maintenance to keep up, given some reasonable amount of discipline. A daily standup works if a day’s worth of change is small enough for people to remember and describe. A sprint review works if a sprint’s worth of change fits in a meeting.
That ratio has moved by roughly an order of magnitude on the reality side and not at all on the maintenance side. Human attention did not get faster. It got scarcer, if anything, because there is now more output to review.
So the same fifteen-minute standup that used to cover a day of team output now covers a fraction of it. The gap does not stay constant, it compounds, because each unreported change makes the next conversation slightly harder to have. By day eleven the board is not slightly stale. It is describing a different project.
The specific mechanics of how it happens
It is worth being concrete, because “the board drifts” is too abstract to act on. There are about five distinct mechanisms and they have different fixes.
Merged but not moved. The most common by far. Work completes, the pull request merges, and the state transition on the ticket is a separate manual act that nobody performs because the work felt finished when the code merged. This produces a board that systematically understates progress, which is the least harmful direction but still causes the reprioritisation described above.
Moved but not merged. The opposite, and more dangerous. Someone drags a ticket to done at the end of a sprint because the work is “basically finished,” and the remaining pull request sits unmerged for a week behind a review or a failing test. The board overstates progress. Downstream teams plan against a capability that does not exist yet.
Work without a ticket. An agent-heavy workflow produces a great deal of small work: fixes, adjustments, follow-ups. Much of it never gets a ticket because creating one for a fifteen-minute change feels absurd. Individually correct. Cumulatively it means a growing share of the team’s actual output is invisible to the board, and the board’s implied capacity model becomes wrong.
Tickets without work. The mirror image. A ticket sits in progress for two weeks with a branch that has three commits from day one and nothing since, because the approach was abandoned in favour of something else and nobody closed the original. These are the quietest and they accumulate, and they poison every velocity number the board produces.
Done that came undone. A ticket closes, then a follow-up pull request changes the behaviour, then another one fixes a regression. The board says done. The work is still moving. Nothing in the board’s model expresses “closed but still churning,” so it cannot be seen.
Notice that three of these five overstate progress and two understate it, which means the errors do not cancel out into a usefully approximate picture. They produce a board that is wrong in different directions in different places, which is much harder to correct for than a board that is uniformly optimistic.
Why “just update your tickets” fails, structurally
The standard response is a discipline push. It fails reliably, and I want to be precise about why, because “people are lazy” is both insulting and wrong.
Updating a ticket after merging a pull request is a duplicate data entry task. The information already exists, in source control, in a form that is more precise than the ticket state. Asking a person to transcribe it is asking them to do work whose output they can already see, which is the exact category of task humans are worst at sustaining. It is not laziness, it is that the task has no local reward. The developer gains nothing from the transition. The gain accrues to someone reading the board later, and diffuse future benefit is the weakest possible motivator for immediate manual effort.
This was survivable when the transcription load was five tickets a week. At thirty or forty units of work a week it becomes a real tax, and taxes with no local benefit get evaded, in every system, always.
The second reason discipline fails is that a meaningful share of the drift is not transcribable at all. “This ticket’s approach was abandoned but part of the work was reused inside another ticket’s branch” is not a state transition. There is no button for it. The board’s vocabulary is too small to describe what actually happened, so even a maximally diligent person cannot represent reality in it.
The decisions that get made on fiction
The reason to care about any of this is not tidiness. It is that boards are load-bearing for decisions that are expensive to reverse.
Prioritisation, obviously. The delivery manager in the opening scene moved a designer and delayed a customer conversation on the basis of a board that was six days behind.
Capacity planning, which is worse, because it is cumulative. If a meaningful fraction of the team’s output never appears on the board, every forecast built from historical throughput is understated, and the team is systematically over-committed against a phantom capacity gap.
Dependency coordination, worse still. Team B watches Team A’s board to know when an interface is ready. Team A’s board says in progress; the interface shipped last week. Team B has been blocked on nothing for five days, and nobody knows, because the whole point of watching a board is to avoid having to ask.
And escalation, which is the one that damages trust the most. Somebody senior looks at a board, sees fourteen in-progress tickets, and concludes the team has a focus problem or a WIP problem. They intervene. The intervention is well-intentioned, evidence-based, and aimed at a problem that does not exist. The team now has to spend political capital explaining that their board is wrong, which is not a comfortable thing to say and sounds like an excuse even when it is true.
That last dynamic is why board drift is more corrosive than it looks. It does not just produce bad decisions. It produces a situation where the team’s own reporting undermines them, and where “the board is inaccurate” becomes an unfalsifiable defence that erodes everyone’s ability to have an honest conversation about delivery at all.
Prioritisation
A designer moved and a customer conversation delayed, on a picture six days stale.
Capacity planning
Cumulative. Output that never reaches the board makes every forecast built on history run low.
Dependency coordination
Team B waits on an interface that shipped last week, because Team A's board still says in progress.
Escalation
The most damaging. The team's own reporting is used as evidence against them, and they cannot refute it.
Reconciliation instead of transcription
The way out is not more discipline. It is to stop treating the board as a hand-maintained original and start treating it as a view that reconciles against something that cannot drift.
Source control is the only artefact in the delivery system that is definitionally true, because it is the work rather than a description of the work. A branch exists or it does not. A pull request is merged or it is not. A review happened or it did not. There is no version of these facts that is out of date, because they are not copies.
So the useful question stops being “is the board correct” and becomes “where does the board disagree with source control, and which of those disagreements matter.” That is a computable question. Merged pull request, ticket not closed. Ticket closed, branch still receiving commits. Ticket in progress, no branch activity in fourteen days. Pull request with no ticket at all. Each of those is a specific, detectable divergence with a specific meaning.
This is the core of what a ground-truth layer does, and it is worth saying plainly that the value is not in the writing back. It is in the detection. A list of the twelve places where your board and your repository disagree is useful even if a human resolves every one of them by hand, because the expensive part was never the state transition, it was knowing which state transitions were needed.
Transcription
- The board is a hand-maintained original
- Humans re-enter what source control already knows
- No local benefit, so the tax gets evaded
- Load scales with output
- Fails at exactly the volumes that matter
Reconciliation
- The board is a view over something that cannot drift
- Software computes the disagreements
- Detection is the value, not the write-back
- Load is constant in output
- Produces a list a human can act on
Where this breaks down
Some genuine limits, including one that undercuts the whole framing.
Source control is not ground truth for everything. I have leaned on “source control is definitionally true” fairly hard, and it is true about code. It is not true about the work. A merged pull request tells you code changed. It does not tell you the feature is usable, that the flag is on, that the migration ran in production, or that the thing the customer asked for was actually delivered. Teams that reconcile boards purely against merge events produce a board that is accurate about code and still fiction about delivery, and that can be more dangerous than the honest version because it looks rigorous. Where a substantial part of your delivery lives outside the repository, in configuration, in infrastructure changed through a console, in a low-code platform, the reconciliation covers correspondingly less and you should discount its confidence accordingly.
Some drift is harmless and chasing it is waste. Not every divergence matters. A ticket that stayed in progress for two days after merging affects nothing. If you build a process that treats all divergence as debt, you will generate a large queue of trivial corrections and burn the team’s tolerance for the whole exercise on items with no decision value. The only divergences worth acting on are the ones somebody would have made a different decision about. That is a much shorter list, and it is worth being ruthless about filtering to it.
An accurate board does not fix a bad plan. This is the one I would most want a reader to sit with. A perfectly reconciled board tells you precisely where you are against a plan that may itself be wrong, badly prioritised, or measuring the wrong things. There is a real risk of teams investing heavily in board accuracy as a substitute for the harder conversation about whether the roadmap makes sense, because accuracy is tractable and strategy is not. I have seen more delivery pain caused by building the wrong thing accurately than by building the right thing with a stale board.
And some teams do not need a board at all. Six people in a room shipping continuously do not have a fiction problem, because their system of record is a conversation and the conversation happens daily with full coverage. Board accuracy is a problem that scales with the number of people who need to know something they cannot find out by asking. Below that threshold, all of this machinery is overhead.
The takeaway
Boards have always drifted. The remediations we built for drift assumed reality changes slowly enough for human transcription to keep up, and that assumption is now false by roughly an order of magnitude. The result is not a slightly stale board but an actively misleading one, produced fast enough that decisions get made on it before anyone notices, and defended by nobody because nobody is at fault.
Discipline will not fix it, because the task has no local reward and the board’s vocabulary is too small to describe what happens anyway. The fix is reconciliation: treat the board as a view over source control, compute the divergences, and act only on the ones that would change a decision.
The next piece looks at the other half of the human bottleneck, the one that does not show up as drift because it shows up as approval: what happens to review quality when the volume rises and rubber-stamping becomes the rational response.