Approval Gates
Approval gates are the points in spec-driven development where a person exercises judgement between phases, before a problem reaches the next phase and becomes more expensive to fix. There are three main gates (one between each pair of core phases) plus the convergence review at the end. They concentrate human review where information is most valuable, instead of scattering it throughout implementation.
If the phases are the body of SDD, the gates are its nervous system: they are the points where problems are caught before they become expensive and where the team gets aligned. The method's guiding principle can be summed up as review at the phase gates, not during implementation. In conversational work, the person programming approves micro-decisions one by one, which leads to approval fatigue; SDD gathers that review into a few points and, once the tasks are approved, implementation runs with minimal intervention because the contract is already clear.
What is reviewed at each gate
| Gate | Question | What is checked |
|---|---|---|
| 1 · Requirements → design | Are we solving the right problem? | Stories that reflect real needs, verifiable criteria, a manageable scope, and identified implicit requirements (security, performance, accessibility). |
| 2 · Design → tasks | Is the design feasible and consistent? | It follows the patterns of the existing code, its decisions are justified, and its dependencies and risks are identified. |
| 3 · Tasks → implementation | Do these tasks, in this order, produce the design? | Coverage with no gaps, correct dependencies, precise prompts, and evaluable success criteria. |
| Convergence | Does what was built match what was specified? | It is the final wrapper of the flow, and the only review that looks at code. |
The logic of the cost of error by phase
Behind the gates lies an economic rationale: the cost of fixing an error grows at an accelerating rate with each phase it passes through. An ambiguous acceptance criterion is fixed during requirements by rewriting a sentence; if it reaches design, the solution has to be rethought; if it reaches the tasks, the breakdown has to be redone; if it reaches implementation, code has to be discarded and regenerated. Every minute spent reviewing a requirement saves hours of reimplementation.
The first three gates review text documents, which makes them more accessible (people who don't code can take part too), faster (reading a spec is quicker than reading code), and more focused (the question "is this what we want?" is kept separate from "is it implemented correctly?", which is reserved for convergence). Approval, however, is a deliberate act, not a formality: a gate that is passed without reading detects nothing and gives a false guarantee.
The review bottleneck
The 2026 evidence adds a counterpoint. The DORA report identifies manual review as the bottleneck that becomes saturated when the rate of code generation rises: the gates concentrate review and, for that very reason, they are the point where the system jams if the capacity to review does not grow at the same pace as the capacity to generate. A poorly sized gate stops protecting and starts slowing things down. Kief Morris frames the question in terms of how people and agents are distributed across the engineering loops: at which points the person brings a judgement that the agent lacks, and at which their intervention only adds latency.
The answer to the bottleneck is not to remove the gate, but to relieve its congestion:
- Delegate approval to whoever has the judgement.
- Allow asynchronous approval, without requiring everyone to be available at the same time.
- Size the specs so that review is short (see Clarity Gate and Curse of Instructions).
- Automate the mechanical: the part of the check that requires no judgement, such as consistency analysis across documents.
Common mistake
Responding to a gate bottleneck by removing the gate. When review becomes a bottleneck, the temptation is to skip it "because of the schedule," right where errors are cheapest to fix. The bottleneck is solved through delegation, asynchrony, shorter specs, and automated checks, not by giving up judgement. Approving without reading is just as harmful: a gate that is not genuinely exercised gives a false guarantee (the method's chapter calls this "specification theater").
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
- DORA. (2026). ROI of AI-assisted Software Development.
- Morris, Kief. (2026). "Humans and Agents in Software Engineering Loops".
- GitHub. (2026). Spec Kit (project documentation).
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.