300 m
The delivery team
Small features need specs the most
Big features get specs because everyone can see the risk. Small features skip them because writing a page for a two-point story feels like theatre. The trouble is that small features are where most of the decisions actually get made: a default value, a validation rule, which record wins when two updates collide. Each one is minor. Together they are the behaviour of the system, and nobody wrote any of it down. Six months later someone asks why, and the only answer is a commit message that says fix.
The fix is not a bigger template. It is a smaller one that is non-negotiable. Every story gets a short spec before build: what changes, what does not, the acceptance criteria written as examples, and any decision the engineer had to make that the ticket did not answer. Half a page is plenty. If it takes longer than the build, the story is too big or the team is overthinking it. Keep it in the repository beside the code so it is versioned with it.
The spec also changes how review works. Reviewers stop asking what the code is meant to do and start checking whether it does what the spec says. That is a faster conversation and a less personal one. It matters even more when agents write some of the code, because an agent will happily build the wrong thing very quickly, and the spec is the only thing it can be held to. Write it down first. It is cheaper than arguing about it later.
