{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"planning-verification-as-work","title":"Putting verification in the plan","url":"https://addaly.com/learn/how-software-changed/planning-verification-as-work","position":54,"of":87,"minutes":8,"answer":"Verification is work, so it belongs in the plan with an oracle, a named person and hours rather than being the residue of whatever time is left.","keyIdea":"Verification is work, so it belongs in the plan with an oracle, a named person and hours rather than being the residue of whatever time is left, and the cheapest version is one sentence naming who confirms what by which method."},"body":{"format":"markdown","text":"## The line that is missing from every plan\n\nAsk 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.\n\nThat 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.\n\nThe 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.\n\n## The three questions at planning\n\nFor every item of any size, before it starts:\n\n1. **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.\n2. **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.\n3. **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.\n\nThese take about four minutes per item and they change what gets committed to.\n\n## A template that fits in a ticket\n\n```markdown\n## Verification plan\nOracle:    differential run against the current pricing service on\n           7 days of replayed production orders; zero divergence except\n           the documented rounding change.\nOwner:     Ananya (build), Ravi from finance (spot-check 20 invoices)\nCost:      ~6h build, ~2h Ravi, 3 days shadow running\nRelease:   flag off, 5% for 48h, halt if checkout completion drops >0.5%\nRollback:  flag off; no schema change in this release\n```\n\nSix 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.\n\nNote 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.\n\n## Definition of done, written once\n\nThe other half of the same problem. Agree a list, keep it short, apply it to everything:\n\n- Merged and deployed to production\n- The oracle named in the plan has been run and passed\n- The flag exists, and its removal is on the board\n- Monitoring shows the new path, and somebody has looked at it\n- The runbook mentions the new failure mode\n- The old code path is deleted, or a ticket exists with a date\n- The specification and any decision record are updated in the same change\n\nThat 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.\n\n## What this changes about capacity\n\nBe 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.\n\nThe 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.\n\nThe 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.\n\n## The smallest version that works\n\nIf a formal template will not survive your team's culture, add one sentence to every ticket:\n\n> **Done when:** _____ has confirmed _____ by _____.\n\nThree 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."},"check":{"question":"A team adds a verification plan to every ticket. Six months later they commit to fewer features per quarter, lead time is down, and change failure rate has halved. How should this be read?","options":[{"text":"The team has become more cautious than necessary, since a halved failure rate suggests over-investment in checking.","correct":false,"tempting":"Treats reliability as a cost to minimise, which invites cutting exactly the practice that produced the improvement."},{"text":"The feature count fell because planning overhead consumed capacity, and the stability gains came from unrelated maturity.","correct":false,"tempting":"Attributes the gains to time passing while attributing the costs to the intervention, which is not a coherent reading of one change."},{"text":"Committed features fell because previously uncounted work is now counted, while the delivery measures improved.","correct":true},{"text":"The comparison is unsound without knowing whether feature size changed, so no conclusion can be drawn from the counts.","correct":false,"tempting":"A fair caution about the feature count alone, but lead time and change failure rate are size-independent and both moved."}]},"prev":{"slug":"work-in-progress-limits","title":"Capping the queue","url":"https://addaly.com/learn/how-software-changed/work-in-progress-limits"},"next":{"slug":"consolidation-and-entropy","title":"Scheduling the deletion","url":"https://addaly.com/learn/how-software-changed/consolidation-and-entropy"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Putting verification in the plan', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/planning-verification-as-work (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Putting verification in the plan","courseTitle":"How Software Development Changed","module":{"index":6,"slug":"teams-and-delivery","title":"Teams, process and delivery"},"answer":null,"keyIdea":"Verification is work, so it belongs in the plan with an oracle, a named person and hours rather than being the residue of whatever time is left, and the cheapest version is one sentence naming who confirms what by which method.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-line-that-is-missing-from-every-plan","runs":[{"text":"The line that is missing from every plan"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-three-questions-at-planning","runs":[{"text":"The three questions at planning"}]},{"t":"p","runs":[{"text":"For every item of any size, before it starts:"}]},{"t":"ol","start":1,"items":[[{"text":"How will we know this works?","b":true},{"text":" 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."}],[{"text":"Who will confirm it, and are they free?","b":true},{"text":" 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."}],[{"text":"What does it cost?","b":true},{"text":" 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."}]]},{"t":"p","runs":[{"text":"These take about four minutes per item and they change what gets committed to."}]},{"t":"h2","id":"a-template-that-fits-in-a-ticket","runs":[{"text":"A template that fits in a ticket"}]},{"t":"code","lang":"markdown","label":"Markdown","text":"## Verification plan\nOracle:    differential run against the current pricing service on\n           7 days of replayed production orders; zero divergence except\n           the documented rounding change.\nOwner:     Ananya (build), Ravi from finance (spot-check 20 invoices)\nCost:      ~6h build, ~2h Ravi, 3 days shadow running\nRelease:   flag off, 5% for 48h, halt if checkout completion drops >0.5%\nRollback:  flag off; no schema change in this release"},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"definition-of-done-written-once","runs":[{"text":"Definition of done, written once"}]},{"t":"p","runs":[{"text":"The other half of the same problem. Agree a list, keep it short, apply it to everything:"}]},{"t":"ul","items":[[{"text":"Merged and deployed to production"}],[{"text":"The oracle named in the plan has been run and passed"}],[{"text":"The flag exists, and its removal is on the board"}],[{"text":"Monitoring shows the new path, and somebody has looked at it"}],[{"text":"The runbook mentions the new failure mode"}],[{"text":"The old code path is deleted, or a ticket exists with a date"}],[{"text":"The specification and any decision record are updated in the same change"}]]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"what-this-changes-about-capacity","runs":[{"text":"What this changes about capacity"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-smallest-version-that-works","runs":[{"text":"The smallest version that works"}]},{"t":"p","runs":[{"text":"If a formal template will not survive your team’s culture, add one sentence to every ticket:"}]},{"t":"quote","runs":[{"text":"Done when:","b":true},{"text":" _____ has confirmed _____ by _____."}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A team adds a verification plan to every ticket. Six months later they commit to fewer features per quarter, lead time is down, and change failure rate has halved. How should this be read?"}],"options":[{"text":[{"text":"The team has become more cautious than necessary, since a halved failure rate suggests over-investment in checking."}],"correct":false,"tempting":[{"text":"Treats reliability as a cost to minimise, which invites cutting exactly the practice that produced the improvement."}]},{"text":[{"text":"The feature count fell because planning overhead consumed capacity, and the stability gains came from unrelated maturity."}],"correct":false,"tempting":[{"text":"Attributes the gains to time passing while attributing the costs to the intervention, which is not a coherent reading of one change."}]},{"text":[{"text":"Committed features fell because previously uncounted work is now counted, while the delivery measures improved."}],"correct":true,"tempting":null},{"text":[{"text":"The comparison is unsound without knowing whether feature size changed, so no conclusion can be drawn from the counts."}],"correct":false,"tempting":[{"text":"A fair caution about the feature count alone, but lead time and change failure rate are size-independent and both moved."}]}],"order":[3,2,0,1],"why":null},"prev":{"slug":"work-in-progress-limits","title":"Capping the queue","minutes":9},"next":{"slug":"consolidation-and-entropy","title":"Scheduling the deletion","minutes":9}}}