The Retro Question That Surfaces Verification Debt

Q: Why don't standard retrospective prompts find verification debt?

What went well and what didn't go well collect things people already recognise as problems. Verification debt is work that looked fine and was accepted without being understood, so it never registers as a problem to raise until it causes an incident.

Last Updated on TBD | By Sanjay Saini | Reviewed by Rishabh Saini | AI-Augmented Verification

“What went well” collects what the team already knows. The most dangerous thing an AI-augmented team ships is the work that looked fine and was never understood — and it takes a different question to pull that into the room.

The standard retrospective is very good at collecting known problems. “What went well, what didn't go well, what will we change” invites people to raise the things they already recognise as things — the flaky pipeline, the late dependency, the meeting that overran. This is useful, and it has a blind spot shaped exactly like the most dangerous thing an AI-augmented team produces.

Verification debt — work accepted into the Increment that nobody genuinely understands — does not register as a problem when it is created. That is its defining property. The pull request looked good. The tests passed. Nobody walked away from that merge thinking “that went badly.” They walked away thinking nothing at all, because nothing appeared to have gone wrong. So when the retrospective asks what didn't go well, verification debt does not raise its hand. It was never filed as a problem in anyone's memory of the Sprint.

To surface something nobody has articulated, you need a question that goes looking for it directly.

The Question

What did we ship this Sprint that nobody here could confidently change?

Read what it is doing. It does not ask what went wrong — verification debt did not feel wrong. It does not ask about mistakes — approving a clean, working, generated change was not a mistake in any ordinary sense. It asks about confidence to change, which is the one symptom present at the moment the debt is created and still present now. A developer may not remember which merges they trust-approved. They will recognise, immediately, the module they would be nervous to touch.

That reframing matters because it separates the finding from blame. “What could you not change” is a question about the state of the code, not the competence of the person. Nobody has to confess to anything. They are reporting a property of the system, and that is a far easier thing to say out loud.

Why This Phrasing

“What went wrong” asks people to recall a problem verification debt never registered as. “What could nobody confidently change” asks about a symptom that is present right now — and frames it as a fact about the code rather than a failing of the reviewer.

Expect Silence, and Hold It

The first two or three times you ask, expect the room to go quiet. This is the hardest moment of the whole practice, and the instinct that will sabotage it is the facilitator's urge to rescue the silence — to soften the question, offer an example, or move on to spare everyone the discomfort.

Do not. The silence is not the question failing. The silence is people running a fast, private calculation: is it safe to be the one who says they approved something they didn't understand? They are watching to see whether you will fill the gap and let them off the hook, and whether the first person to speak gets treated as having admitted a weakness. What you do in those ten seconds tells them the answer more clearly than anything you could say.

So let it sit. If you must do anything, restate the question once, unhurried, and wait again. The first honest answer is worth more than any amount of comfortable discussion, and it will not come if the room learns that silence gets rescued.

The Answer Is the Beginning, Not the End

When someone does name a module, what you do next decides whether the question ever works again. Two responses kill it permanently.

The first is any hint of blame — a raised eyebrow, a “how did that get approved,” anything that makes the speaker regret speaking. Do that once and you have taught the whole room that honesty is punished, and the flag reports zero debt forever after. The second, subtler failure is to do nothing: to nod, thank them, write it on a sticky note, and let it evaporate. If naming debt leads to no action, people stop bothering, not out of fear but out of futility.

The response that keeps the question alive treats the answer as data and turns it into a decision:

Turn the named debt into a deliberate choice, not a sticky note that evaporates.
The answer names…	A useful next move
Debt in a critical area	A Product Backlog item to build comprehension — someone reads it, understands it, and can defend it next Sprint.
Debt in a low-risk area	A conscious decision to accept it, recorded in the debt register. Deliberate is the goal, not zero.
A recurring pattern of trust-approvals	An impediment about the review process itself — the pressure or habit that keeps producing it — not about the individual change.

The distinction to protect, out loud, is that naming debt is not confessing to a failure. Outside high-criticality work, carrying some verification debt is a rational trade for the speed AI generation buys. The retrospective is not there to drive it to zero. It is there to make sure the team's holdings are visible and chosen rather than accumulated by accident in whichever module happened to attract the most trust-approvals. A team that decides to hold debt is in control. A team that discovers it during an incident is not.

Fitting It Into the Retrospective You Already Run

This does not replace your retrospective format; it is one question inside it, and it does not belong in every single Sprint where it would become rote. A reasonable rhythm is to ask it whenever the Sprint involved significant generated work, and to let the debt register carry the memory in between. Over a few months the pattern in the answers — which parts of the system keep coming up — is often a more valuable finding than any single Sprint's response, because it shows you where trust-approval concentrates when nobody is steering it.

What to Do Next Retrospective

Ask the question once, cleanly, and stop talking.
Hold the silence. Do not soften it, do not offer an example, do not rescue the room.
Receive the first answer as data — no blame, visible follow-through.
Turn each answer into a decision: remediate it, consciously accept it, or treat a recurring pattern as a process impediment.

Part of AI-Augmented Verification

The retrospective is the last net. What review let through and acceptance criteria didn't catch, this question is the team's chance to name before it becomes an incident.

Comprehension at Review → Verification Debt → The Retro Question

All Verification Practices Verification Debt Reviewing Code Nobody Wrote

Frequently Asked Questions

What retrospective question surfaces verification debt?

Ask what the team shipped this Sprint that nobody present could confidently change. It targets the space of things nobody has articulated — where verification debt lives — rather than the known problems that “what went well” collects.

Why don't standard prompts find it?

“What went well” and “what didn't” collect things people already recognise as problems. Verification debt is work that looked fine and was accepted without being understood, so it never registers as a problem to raise until it causes an incident.

What do you do when nobody answers?

Hold the silence rather than rescuing it with an easier question. The pause is people deciding whether an honest answer is safe, and how the first answer is received decides whether anyone offers a second one in future retrospectives.

Is verification debt a sign the team is doing something wrong?

No. Outside high-criticality work, some verification debt is a rational trade-off for the speed AI generation gives. The retrospective is about making the team's holdings visible and deliberate — not about eliminating them or assigning blame.