VDD Methodology Specification v 1.0
The normative rules of VDD: how work is counted in Delivery Bricks, how every Unit is verified, how a Brick is priced, how delivery dates are forecast, and how changes are re-priced. This page is an overview. The full Specification, with every definition, counting rule, formula, and example can be downloaded from our web site.
Four questions, one set of numbers
What
What will be built: a set of Delivery Bricks.
How much
Bricks × a Price per Brick calibrated on your own history.
When
A P50 and P85 range, recalculated from actual throughput.
Accepted how
Through the Independent Verification Gate.
VDD replaces the units of estimation and price, not your delivery process: it is used alongside Scrum, Kanban or a phased process, and applies equally to code written by people and generated by AI.
VDD Manifesto
"We value verified units of work over billed hours."
A Delivery Unit is priced by what it is made of and how it was checked, not by how long someone sat typing.
"We value expert judgment and knowledge more than the speed of code generation."
Every Unit passes through an Independent Verification Gate: an engineer who did not write it must check it and confirm it before it counts as delivered.
"We value a price that reflects the system's quality, complexity, and reliability rather than one based on code volume or hours spent."
Bricks carry complexity modifiers tied to real risk.
"We value a transparent, explainable basis for price over abstract hours."
Price is calibrated from the organization's own delivery history.
"We value conclusions and estimates grounded in data and statistics rather than arbitrary judgment."
Timelines are a probability range, not a guess: the P50/P85 model is recalculated after every sprint using actual throughput.
Glossary
Delivery Brick
Minimal, objectively countable unit of engineering work. Not a unit of time or AI compute. The count doesn't change based on how long something took.
Delivery Unit
A complete, fully working, independently verified user story. 1 Unit = the sum of its Bricks, from code to testing.
Independent Verification Gate
Mandatory step where someone who did not build a Unit confirms it from scratch before it counts as delivered.
Base Unit Rate
The monetary value of one Brick in a given category, calibrated from the organization's own historical revenue. Not a specialist's hourly wage.
Customer Risk Multiplier
Documented coefficient applied only to the guaranteed P85 date (never P50), reflecting history with a specific client.
Brick Categories
Open research whose units of work are unknown in advance is not counted in Bricks. It is a time-boxed Research Spike.
How price and dates are set
Price per category
Each category has its own Base Unit Rate, calibrated on revenue from your verified deliveries and weighted by its Independent Verification Effort. Never an hourly rate.
P50 and P85
The median and the 85th-percentile throughput of completed sprints. Both dates are always reported and recalculated every sprint.
Re-Bricking
A requirement change recounts only what changed, so both sides see the delta in Bricks, price and dates before agreeing.
When an organization applies VDD
Work is counted in Delivery Bricks by the twelve categories, or documented internal extensions of them.
Every Delivery Unit passes the Independent Verification Gate.
Bricks are priced per category from rates calibrated on the organization's own history, or marked preliminary.
Delivery dates are reported as P50 and P85 and recalculated from actual throughput.
VDD can be applied entirely by hand, with spreadsheets. No tool is required.
The full Specification defines every term used in VDD and sets out the counting rules and complexity modifiers for all twelve Brick categories, including the Data & Edge modifiers for AI and computer-vision work. It specifies the Independent Verification Gate, the pricing model with the formulas for the Base Unit Rate, Independent Verification Effort, complexity coefficients, and the Price per Brick, and the forecasting model with P50, P85, and the Customer Risk Multiplier. It also gives the Re-Bricking procedure for requirement changes, the four requirements for applying VDD, worked examples, and the historical background of the methodology. The Specification is sent to your inbox together with the Implementation Playbook, the spreadsheet templates and the presentation.