Measuring drift, and why it predicts slippage

The thing about a date slipping is that it never slips on the day it slips. Somebody stands up in a meeting six days before the deadline and says the fourteenth is not going to happen, and everyone reacts as though new information has arrived. It has not. The information has been sitting in the systems for three weeks. What arrived is somebody finally looking.

I have become interested in what, exactly, was observable during those three weeks, because if the answer is “nothing” then slippage is genuinely unpredictable and we should all stop pretending otherwise. But the answer is not nothing. There is a signal, it is cheap to compute, and it is not in any of the places people normally look.

The signal is drift: the measurable disagreement between what your system of record claims and what your source control shows.

Drift as a quantity

Drift usually gets discussed as a vibe. “The board is out of date.” That framing makes it a hygiene issue, which makes it low priority, which is why it never gets fixed. Treating it as a measurable quantity changes the conversation, because quantities have trends and trends have implications.

Concretely, drift is a set of specific disagreements you can count by joining two systems you already pay for.

Work items in progress with everything merged. The work is done. The record says it is not. Every forecast computed from that record is understating your position.

Work items marked done with unmerged or unopened work. The record says complete. Nothing, or not everything, has landed. Every forecast is overstating.

Work items in progress with no branch, no pull request, no commit. Claimed as active, no evidence of activity. Sometimes this is design work or discussion, which is legitimate. Frequently it is a card somebody dragged optimistically at sprint planning and nobody touched since.

Merges with no linked work item. Reality being created outside the record entirely. This is the one I have flagged in nearly every piece in this series, and this is the piece where its importance is clearest, because unlinked merges are drift at its source: work happening that the record has no representation of at all.

Stale in-progress age. How long items have been claimed as active. A distribution rather than a count, and its long tail is where organisational fiction accumulates.

Five numbers. All computable from data you already have. None requiring anybody to fill anything in.

In progress, everything mergedThe work is done and the record says it is not. Forecasts understate your position.

Done, with work unmergedThe record claims complete and not everything landed. Forecasts overstate.

In progress, no evidence at allNo branch, no commit, no pull request. Sometimes legitimate design work. Frequently not.

Merges with no work itemReality being created outside the record entirely.

Stale in-progress ageA distribution rather than a count. The long tail is where organisational fiction accumulates.

The mechanism that makes drift predictive

Here is the argument, and it is worth following carefully because the causation is not the obvious one.

Drift does not cause slippage. It is not that a stale board makes a project late. The relationship is that both are downstream of the same thing, and drift surfaces first.

What produces drift? Attention shortage. A record gets updated when somebody with knowledge of the work has a spare moment and the inclination to reconcile. When that person is under pressure, the reconciliation is the first thing to go, because it is the only part of their job with no immediate consequence for skipping it. Nobody has ever had a production incident because a ticket was in the wrong column today.

What produces slippage? Also attention shortage, but with a longer transmission delay. The pressure that made people stop updating the board is the same pressure that means work is going slower than planned, that dependencies are not being chased, that decisions are queueing behind people who have no time to make them.

So drift and slippage share a cause. Drift responds within days because record-keeping is the lowest-priority activity and therefore the most sensitive indicator of load. Slippage responds within weeks, because schedules have slack in them and because people work harder before they miss a date.

That delay between the two responses is the entire value of the measurement. You are not predicting the future. You are reading a fast-moving symptom of a condition whose other symptom is slow-moving.

Attention shortageThe shared cause. Pressure rises, and reconciliation is the lowest-priority activity anyone has.

Drift, within daysRecord-keeping is the most sensitive indicator of load, so it moves first.

Slippage, within weeksThe same pressure, transmitted through a longer delay.

There is a second, more mundane mechanism worth naming. A drifting record makes decisions worse, and worse decisions make slippage more likely. Priorities set from a stale board misallocate people. Reviews get queued in the wrong order. Dependencies get chased late because nobody knew they had landed. This is a genuine causal path from drift to slippage, and it means drift is both an indicator and a contributing factor.

What to actually watch

Levels are close to meaningless, because every organisation has a baseline drift determined by its culture and process. Some teams run at a reconciliation gap of two items and some at thirty, and both can be healthy or unhealthy depending on their size and how much anyone relies on the board.

What matters is the derivative. Three patterns to look for.

Sudden rise in reconciliation gap. Within a week or two of a change in conditions: a reorganisation, a key person leaving, a crunch period, an ambitious sprint commitment. If the gap jumps and does not come back within a cycle, the load did not come back either.

Rising unlinked merge share. Slower moving and more serious. This is the record losing coverage rather than losing currency, and it does not self-correct, because there is no natural moment at which an unlinked merge gets linked. Once work is happening outside the record, it stays outside.

A lengthening stale-in-progress tail. The distribution matters here. A team with fifteen items in progress, fourteen of which moved this week, is healthy. The same team with one item that has been in progress for six weeks has a specific problem hiding in it, and it is usually blocked on something nobody has escalated.

None of these three needs a dashboard. All of them are a weekly query and a five-minute look.

Levels tell you nothing

• Every org has a baseline set by its culture
• Two items or thirty can both be normal
• Comparing across teams is meaningless
• A target on the level invites gaming

The derivative is the signal

• Sudden rise after a change in conditions
• Rising unlinked merge share: coverage loss, does not self-correct
• A lengthening stale tail
• A weekly query and a five-minute look

Drift under the ADLC specifically

Everything above was true before agents. What changed is the rate.

Drift accumulates when the flow of real change outpaces the human capacity to record it. Agentic development multiplies the flow and leaves the recording capacity flat. The gap that used to open over a sprint now opens over an afternoon, which changes not just the magnitude but the nature of the problem.

At sprint speed, drift was correctable by ceremony. That is what standup was for and it worked, because a day’s drift was small enough for a person to hold in their head and repair in fifteen minutes. At agent speed, ceremony cannot keep up: fifteen minutes of standup does not reconcile forty merges, and nobody can hold the mapping.

Which means the response to drift under the ADLC cannot be more discipline. Discipline is a human-attention solution to a problem whose defining feature is that human attention is the scarce resource. The only response that scales is automatic reconciliation from ground truth: matching branches and pull requests to work items and updating the record from what actually happened. That is the thing GroundTruth exists to do, and I would say the same if it did not, because the arithmetic does not leave another option.

The measurement still matters even after you automate the reconciliation, because reconciliation coverage is never total. There will always be work the automation cannot match, and the residual gap is exactly what you want to be watching.

Where this breaks down

Several important limits.

The predictive claim is a mechanism, not a validated finding. I have argued that drift leads slippage because both are downstream of attention shortage and drift responds faster. That argument is plausible and it matches what I observe, and I have no study establishing a lead time, an effect size, or a false positive rate. Anyone quoting a specific correlation to you should be asked where it came from. Treat drift as a prompt to go and ask a question, not as a forecast input.

It only works where the record is load-bearing. A small co-located team whose real coordination happens in conversation will show high drift and suffer nothing, because the board was never how they knew anything. Measuring drift there tells you about their relationship to a tool they correctly ignore. The metric earns its place when the record actually feeds decisions: multiple teams, cross-team dependencies, stakeholders not in the room, anything with a committed date attached.

Measuring it can destroy it. If reconciliation gap becomes a number teams are held to, the cheapest way to improve it is to update tickets in bulk without regard to accuracy, usually on a Friday. You then have a low drift number and a record that is exactly as fictional as before, minus the visible symptom that used to warn you. This is the classic failure of any hygiene metric, and it is why drift should be closed by automation against ground truth rather than requested from people.

Not all drift is bad. Some work legitimately has no source control footprint: design, research, stakeholder negotiation, a week spent untangling a vendor contract. Those items sit in progress with no branch and no pull request, and a naive drift measure flags them as fiction. If your organisation does a lot of this, your baseline will be high and the level will be uninformative. The derivative still works, provided the mix of work is stable, which it often is not.

The attention-shortage story is not the only explanation. Drift also rises when a team changes tools, when a new joiner does not know the conventions, when someone reorganises the board, or when a process change makes the old workflow states wrong. All of those produce a jump that has nothing to do with delivery risk. The metric tells you something changed. It does not tell you what, and the temptation to assume the alarming explanation should be resisted for at least one conversation.

The takeaway

Drift is measurable: five counts, joined from your tracker and your source control, none of them requiring anybody to fill anything in. It moves fast because record-keeping is the first thing people drop under load, and slippage moves slowly because schedules have slack. That difference in response time is what makes drift worth watching.

Watch the derivative, not the level. Investigate rises rather than assuming their cause. Close the gap by reconciling automatically against source control rather than by asking people to be more diligent, because diligence is human attention and human attention is the resource that ran out.

The next piece explains how all of this can be computed without instrumenting anything, by reading artefacts your team already produces rather than asking it to produce new ones.