Spec-driven development and the backlog

Spec-driven development is the practice of writing a structured specification before any code, having a coding agent turn it into a technical plan and a list of tasks, and then implementing against those tasks with the spec as the source of truth. It became popular as agents took on larger pieces of work, where prompting your way through a feature one message at a time produces code that drifts from what anyone intended.

Tools such as GitHub's Spec Kit and AWS's Kiro build the workflow in. This article explains what the approach adds, how its artefacts map onto a backlog you may already have, and the decision that matters most: where the spec should live.

What the approach adds

A spec-driven workflow separates three questions that a single prompt tends to blur.

• What and why. Requirements and user-facing behaviour, written without reference to the implementation.
• How. A technical plan: the architecture, the data model, the interfaces, the constraints.
• In what order. Tasks small enough to implement and check one at a time.

The agent works through the tasks, and the spec stays the reference it is checked against. Spec Kit's documentation sums up the first rule as "Define what and why before deciding how to build it." The discipline is not new; it is the separation between requirements, design and work items that good backlogs have always had. What is new is that the reader of all three documents is now often an agent, which follows them more literally than a person would.

How the tools implement it

GitHub Spec Kit is an open-source, MIT-licensed toolkit. Its specify command-line tool sets a project up for your coding agent, and the workflow then runs as a sequence of agent commands: a constitution of project-wide principles, specify for requirements and user stories, plan for the technical design, tasks to break the plan into ordered steps, implement to execute them, and converge, which checks the codebase against the spec, plan and tasks after implementation and adds tasks for anything missed. The exact spelling of each command depends on the agent you use it with.

Kiro, from AWS, builds specs into its agentic development environment. A feature spec produces three files: requirements.md, holding user stories with acceptance criteria written in EARS notation (WHEN a condition occurs, THE SYSTEM SHALL respond in a stated way), design.md and tasks.md, whose discrete tasks you run and track one at a time. A bugfix spec uses bugfix.md in place of the requirements file.

Without a dedicated tool, the same shape works in any agent. Anthropic's guidance for Claude Code suggests having the agent interview you about a larger feature, writing the result to a spec file, and then starting a fresh session to implement it, so that the implementation starts with a clean context and a written reference.

How spec artefacts map onto a backlog

If your team keeps a backlog, you already have most of these artefacts under other names.

Spec-driven artefact	Backlog equivalent
Constitution, or project principles	The repository's instruction file, plus accepted architecture decisions
Requirements and acceptance criteria	An epic and its stories, each with acceptance criteria
Technical plan or design	Design notes, architecture decision records and diagrams linked to the stories
Tasks	Sub-tasks, or one story per task when each task is a reviewable change
Implementation	Branches and pull requests linked to the stories they implement

The mapping matters because it shows the real choice. Spec-driven development does not ask you to create new kinds of document. It asks you to write the ones you have more precisely, and it forces a decision about where they live.

Where the spec should live

There are two reasonable answers, and one unreasonable one.

In the repository, as Markdown next to the code. The spec is versioned with the change, reviewed in the same pull request, and read by the agent without any extra connection. The costs: people who do not read the repository (product managers, testers, support, leadership) do not see it; it has no status, owner or links to tests and defects; and once the feature ships, nothing prompts anyone to keep it current. For a single team or an open-source project where everyone works in the repository, this is often the right answer.

In the tracker, as the stories, acceptance criteria and linked designs. Everyone sees it, it has owners and status, and it links to the tests and defects that come later. The cost is that the agent needs access to it. A pasted copy goes stale the moment someone edits the story, which is why this option only works well when the agent reads the tracker directly, typically over MCP. See backlog access for coding agents over MCP.

In both, maintained by hand, is the unreasonable answer. Two copies of a specification drift apart as soon as one is edited, and an agent reading the stale one builds the wrong thing with complete confidence. Choose one source of truth per artefact. If the spec lives in the repository, link to it from the story. If it lives in the tracker, give agents read access and do not copy it into the repository.

Stride takes the second approach: stories, acceptance criteria, designs and decisions are linked records in one graph, served to coding agents over MCP. We think it is the better default for teams where people outside engineering need to read and change the spec, and we would not argue a small team out of a repository-first spec that works for them.

What spec-driven development does not fix

A precise spec is not a correct one.

• A well-specified wrong feature is still wrong. The spec needs review by someone who knows what the user needs, and that review is worth more than any amount of review of the code.
• Nobody reads a spec that is too long. Specs that run to many pages get approved unread, exactly like oversized pull requests. Split the feature.
• Small changes do not need the ceremony. A one-line fix or a rename needs a clear request and a check, not requirements, a plan and a task list. Anthropic's guidance makes the same point about planning in general: when you could describe the change in one sentence, skip the plan.
• Specs go stale after launch. Decide who updates the spec when behaviour changes later, or mark it as historical once the feature ships.

A lightweight way to start

You do not need a new tool to try the approach on your next feature.

1. Have the agent interview you and draft the requirements, with acceptance criteria for each story, including the "must not" cases.
2. Review and approve the requirements before any design work. This is the most valuable review in the whole process.
3. Have the agent propose a technical plan, and record any real decision in it as an architecture decision record linked to the stories.
4. Break the plan into tasks that are each one reviewable pull request, and put them in the backlog as stories or sub-tasks.
5. Implement one task per session, test-first, and review each pull request against its task's acceptance criteria.
6. When implementation reveals the spec was wrong, change the spec first, then the code.