Verification Debt

A pull request arrives. It is well formatted. The tests pass. The description is clear and slightly better written than the ones your team usually produces. A developer reads it, finds nothing wrong, and approves it. Two minutes, start to finish.

Nothing in that sequence is a policy violation. The Definition of Done was satisfied. And yet something happened that would not have happened two years ago: the change entered the Increment without anyone on the Scrum Team acquiring an understanding of it. The reviewer did not find the change acceptable. The reviewer found no reason to object, which is a different thing.

Repeat that a few hundred times across a couple of quarters and you have a system your team owns on paper and cannot change in practice. That gap has a name worth using: verification debt — the first of the AI-augmented verification practices.

A Working Definition

Verification debt is work accepted into the Increment that no human on the Scrum Team genuinely understands.

It is not a synonym for technical debt, and collapsing the two costs you the ability to act on either. Technical debt is a known compromise. Someone understood the problem, chose a shortcut, and can usually describe what it would take to undo it. It is a liability the team can estimate.

Verification debt is different in kind. There is no shortcut anyone chose, because there was never a moment of understanding to shortcut. The team cannot estimate the cost of fixing it, because estimating requires the comprehension that is precisely what is missing.

Why It Accumulates Without Anyone Deciding To

Every incentive in a well-run Scrum Team points toward approving the change.

The artifact looks good

Generated code is usually idiomatic, commented, and conventionally structured. The surface signals that human reviewers have spent a career learning to read as evidence of care are now free. A reviewer scanning for the usual smells finds none, because the usual smells were symptoms of human haste.

The tests pass — and the tests may have been generated too

If the same context that produced the implementation produced the test, the test encodes the same misunderstanding. Passing means the code agrees with itself.

Approving is fast, and admitting confusion is slow

This is the part that is genuinely a Scrum Master concern rather than an engineering one. Saying “I do not follow this change” costs the reviewer something socially. It reads as a confession about their own capability rather than a statement about the artifact. Saying “looks good to me” costs nothing and clears the board. When one option is free and the other is expensive, teams do not need a policy to make the wrong choice consistently. They only need a normal amount of Sprint pressure.

The metrics reward it

Throughput rises. Cycle time falls. Every dashboard the team is judged by improves in the same Sprint the debt is created. There is no counter-signal in the room until much later, and by then the connection to the decision is invisible.

So the accumulation is not a discipline failure. It is what a competent, well-intentioned team produces when the cost of a decision arrives one or two quarters after the decision, and lands on someone else.

Three Instruments That Make It Visible

You cannot inspect what you cannot see, and Scrum's empiricism assumes the team can inspect the thing it is adapting. That assumption is what breaks here — which means the work is to restore visibility before anything else.

1. The comprehension flag

At review, the reviewer records one of three states rather than a binary approval:

• Understood — I can explain what this does, why it does it that way, and what happens when it fails.
• Partially understood — I follow the intent and the shape, but not all of the implementation.
• Approved on trust — I found no reason to object. I could not reproduce this reasoning or defend it.

Mechanically this is trivial: a checkbox, a label, a commit trailer. The mechanism is not the hard part. The hard part is that the third option must be socially safe to select. If a developer believes that choosing “approved on trust” marks them as weak, they will choose it once, observe what happens, and never choose it again. The instrument then reports zero debt forever, which is worse than having no instrument — because now the team has evidence.

Creating that safety is Scrum Master work in the most literal sense. It is coaching the Developers toward self-management, and it usually requires the most senior person in the team to select “approved on trust” first, in public, without apology.

2. The verification debt register

A simple list of components carrying trust-approved work, with the age of the oldest entry. It should look uncomfortable, and it should get more uncomfortable over time, because that is an honest representation of the risk.

Where this earns its place is the Sprint Review. When a stakeholder asks whether the team can take on a change to a particular area, the register turns a vague hesitation into a specific statement: this component contains four months of work nobody has read closely, so a change there carries risk we cannot currently size. That is a far better conversation than padding an estimate and hoping.

3. Rework attribution

Of the rework the team did this Sprint, what proportion originated in trust-approved work?

This is the number that changes the conversation with leadership, because it converts a concern into a cost. “We should understand our code better” is a preference, and it loses every argument against a delivery date. “Thirty-one percent of last quarter's rework came from changes nobody reviewed properly, and here is the register showing where the rest of it is waiting” is a budget argument — and budget arguments get funded.

The Retrospective Question That Surfaces It

Standard retrospective prompts will not find verification debt. “What went well, what did not go well” collects things people already know they know. Verification debt lives in the space of things nobody has articulated, so it needs a question shaped to pull it out:

Expect silence the first two or three times you ask. Hold it, do not rescue the room, and do not follow it with a softer question. The silence is not a failure of the question — it is people deciding whether the answer is safe to say out loud. What you do with the first honest answer determines whether you ever get a second one.

Zero Is the Wrong Target

It would be easy to read all of this as an argument against using AI to generate code. It is not — and if your team hears it that way, you have lost them for a reason that is your fault rather than theirs.

Outside high-criticality areas — safety, security, regulated function, anything where a failure is not recoverable — some verification debt is a rational trade. A team that insists on complete comprehension of every generated line has given up most of the benefit and will be outrun by teams that did not. That is a real competitive cost, not a hypothetical one.

The failure mode is not having verification debt. It is having it unknowingly, distributed unevenly across the system, concentrated by accident in exactly the components you will need to change under time pressure. A team that can say “we hold roughly this much, here, and we have decided that is acceptable” is in a completely different position from a team that has never asked.

Where This Connects to the Rest of Scrum

Nothing here requires a change to the framework, and you should be suspicious of anyone selling you one. The accountabilities, events, and artifacts hold. What has moved is the constraint operating inside them.

The Definition of Done was written under an assumption that is now false: that whoever wrote the code understood it while writing it. Comprehension used to be a free by-product of authorship, so no Definition of Done ever needed to ask for it. Now it has to be asked for explicitly.

Acceptance criteria face a parallel problem when the feature itself is probabilistic. Given-When-Then assumes a deterministic system and quietly stops meaning anything when output varies run to run — which is why acceptance criteria for AI features have to become evals.

And the Developers remain accountable for an Increment that meets the Definition of Done. Agents are capacity, not members of the Scrum Team. Capacity does not hold accountability, and no volume of generated work transfers any part of it. That principle is doing quiet load-bearing work throughout this article: verification debt exists as a concept only because accountability stayed human while authorship did not.

What to Do Next Sprint

1. Add the three-state comprehension flag to code review. Do not announce it as a policy — introduce it as an experiment with an end date.
2. Have the most senior developer select “approved on trust” first, visibly.
3. Ask the retrospective question. Once. Let the silence run.
4. After three Sprints, look at where trust-approvals cluster. They will not be evenly spread, and the pattern is the finding.