Putting verification in the plan

The line that is missing from every plan

Ask any team what a feature costs and you get a number for building it. Verification is a residue: whatever time is left before the deadline, done by whoever is available, at whatever depth is possible.

That arrangement was tolerable when building was the expensive part. It is not tolerable when building is fast and confirming is the constraint, because the residue of a shorter build is a smaller residue, and the amount of confirming required went up.

The fix is procedural and dull: verification appears in the plan as a named line, with an owner and hours, and it is estimated before the work starts rather than discovered afterwards.

The three questions at planning

For every item of any size, before it starts:

1. How will we know this works? Not “we’ll test it”. Which specific mechanism: a property, a differential run against the old path, a staged rollout with a metric, a person from finance checking twenty rows against their spreadsheet.
2. Who will confirm it, and are they free? A name. If the only person who can judge whether the tax calculation is right is on leave for two weeks, that is the schedule, whatever the code takes.
3. What does it cost? In hours. If verification is a third of the estimate, that is normal for anything that touches money, and it should be in the number the stakeholder hears.

These take about four minutes per item and they change what gets committed to.

A template that fits in a ticket

## Verification plan
Oracle:    differential run against the current pricing service on
           7 days of replayed production orders; zero divergence except
           the documented rounding change.
Owner:     Ananya (build), Ravi from finance (spot-check 20 invoices)
Cost:      ~6h build, ~2h Ravi, 3 days shadow running
Release:   flag off, 5% for 48h, halt if checkout completion drops >0.5%
Rollback:  flag off; no schema change in this release

Six lines. Every one of them is a decision that would otherwise be made under time pressure at the end, by whoever is available, with worse information.

Note what the presence of “Ravi from finance, 2h” does. It converts an implicit dependency into a scheduled one. Half the reason features stall at 95% is a person who did not know they were needed.

Definition of done, written once

The other half of the same problem. Agree a list, keep it short, apply it to everything:

• Merged and deployed to production
• The oracle named in the plan has been run and passed
• The flag exists, and its removal is on the board
• Monitoring shows the new path, and somebody has looked at it
• The runbook mentions the new failure mode
• The old code path is deleted, or a ticket exists with a date
• The specification and any decision record are updated in the same change

That list is where features go to sit for three weeks. Writing it down does not make it shorter. It makes it visible, and visible work gets scheduled instead of being discovered.

What this changes about capacity

Be straightforward about the consequence: putting verification in the plan reduces the number of features a team commits to per quarter. It has to, because the work was always there and was previously not counted.

The defence is that it was not free before either. It was paid in change failure rate, in incidents, in rework, and in the three weeks a feature spent apparently nearly done. Those costs are larger and they arrive at worse moments, but they are charged to a different account, which is why they were tolerated.

The measurable claim to make and then check: after two quarters of planning this way, deployment frequency should be flat or up, lead time down, and change failure rate down. If those three do not move, the extra planning was ceremony and you should stop.

The smallest version that works

If a formal template will not survive your team’s culture, add one sentence to every ticket:

Done when: _____ has confirmed _____ by _____.

Three blanks. Filling them in takes twenty seconds and it forces a name, an oracle and a method. Most of the benefit of everything above comes from that one line.