Proportionality principle
The proportionality principle is the rule that governs the sensible application of spec-driven development: matching the intensity of the process to the size of the problem. A minor defect does not need a four-phase spec; a complex feature that affects several parts of the system does. Poorly calibrated, SDD turns into a specification bureaucracy that slows things down instead of speeding them up.
SDD is not a form to be filled out mechanically. Knowing when not to apply it is part of mastering it: agile wisdom is contextual, and no practice is always good or always bad. Most of the method's failures are calibration failures.
The case of the sledgehammer and the nut
Birgitta Böckeler documented a revealing case. When she asked an SDD tool to fix a small defect, the generated requirements document turned the task into four user stories with 16 acceptance criteria. She described it as using a sledgehammer to crack a nut. Overapplication also carries a hidden cost that doesn't show up on the clock: once the team learns that any change triggers the full workflow, it starts avoiding the workflow, and with it the gates that actually provided protection. Excessive rigidity doesn't produce rigor; it produces shortcuts.
The calibration question
The practical heuristic comes down to a single question: what happens if the agent makes the wrong decision at this point?
- If the answer is "I can fix it in two minutes," that point doesn't need to be specified.
- If the answer is "I lose hours or introduce a subtle defect," it does.
SDD adds net value when the change is substantial, there is ambiguity, there is risk, more than one person or agent is involved, or the code must be maintained over time. When none of these conditions is met, vibe coding is still the right tool: a single-use script, a prototype for a demo, or a one-line change does not warrant the full workflow.
The Gradient Shown by the Evidence
The 2026 DORA report reinforces the principle from another angle: the return on AI is high for new, simple work and much lower for complex legacy code. Process intensity cannot be the same at both extremes. Where AI gets things right almost on its own, heavy specification is a cost with no return; where AI stumbles over the system's history, the spec is what keeps that stumble from reaching production. The principle, therefore, does not just protect against excess: it also shows where to invest.
Common mistake
Confusing exhaustiveness with quality. More phases and more criteria do not make for better SDD; they are often the sledgehammer used to crack a nut. Applying the same intensity to a trivial defect and to a complex feature breeds bureaucracy and, later, shortcuts. And forgetting that vibe coding still has its place: for scripts, prototypes, and trivial changes, specifying is a cost with no return.
Resources
📊 Guía didáctica SDD [SDD Teaching Guide, in Spanish]Resources · Scrum Manager
🏦 SDD en equipos ágiles [SDD in Agile Teams, in Spanish]Skill Arena · Scrum Manager
References
- Böckeler, Birgitta. (2025). "Understanding Spec-Driven Development." Thoughtworks / martinfowler.com.
- DORA. (2026). ROI of AI-assisted Software Development.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.