Specification by Example
“Gojko Adzic's approach, where concrete examples become automated tests.”
The requirement looked clear. Development built what they understood. Testing found it wasn't what the stakeholder meant. Everyone's pointing at the same sentence and reading it differently.
Specification by Example is Gojko Adzic's approach where concrete examples serve triple duty as requirements, documentation, and automated tests. You write Given-When-Then scenarios collaboratively — business and technical people together — forcing the precision that natural language lets everyone avoid.
The unique strength is closing the gap between what stakeholders want, what developers build, and what testers verify. The examples become living documentation that stays accurate because it's executable — it can't go stale the way a specification document does.
Reach for it when ambiguity in requirements is causing rework. It falls apart without automation capability to keep the examples running, and it's wrong for exploratory work where the team is still discovering what the feature should do.
Your next move: Could your team write three concrete examples of the next feature working correctly before they start building it — and if not, is the requirement actually clear, or just clear enough to misinterpret in different ways?
What it looked like for them
Mark Barwald, mass-customised jeans, early 2010s. Barwald's startup offered roughly twelve million jean configurations. The specification was abstract: any combination of leg shape, inseam, waist, wash, and pocket style was technically available.
Nobody had written down concrete examples of what real customers would actually order. When orders arrived, ninety per cent were the same handful of configurations — standard fits for tall women in dark washes. The abstract specification said "anything is possible." The concrete examples said "five things matter."
The gap between those two was the entire excess cost of the supply chain. Specification by example works because it forces the team to write the real cases before building the system. Barwald's team had specified what was possible. They hadn't specified what was likely.
A handful of concrete customer orders, written as examples before the supply chain was built, would have shown the concentration pattern and saved the company from building infrastructure for twelve million combinations when five would have covered the market.
“The deadline moved and nobody told my team.”