Spec-driven development in a team, and in Scrum

Published 23 October 2026

In a team, spec-driven development stops being one developer’s habit and becomes an agreement — and that is where most of its benefit lies, if the agreement is set up. The pattern that works: one person drafts the spec with the agent, the team and whoever owns the decision review it before the build, one named person keeps it current, and the build happens on a branch that carries the spec. In Scrum the ceremonies barely change: refinement becomes a review of the spec, the definition of ready includes an agreed spec, and the definition of done includes a spec that matches what was built. What goes wrong is also predictable: conflicting specs, specs nobody reads, and process that costs more as the agents get faster. Below are the roles, specs in git and across repositories, many agents working from one spec, what changes in Scrum, the objections, and how to roll it out.

The workflow is obvious when you are just one person, but I can’t imagine the workflow when there are 5 other developers in the team and a BA, and we have Jira/Linear/etc, sprint planning, and so on.

— the author of a post on r/ClaudeCode asking how to do spec-driven development in a team, 2026

Why a team changes the picture

The largest study of spec-driven development in practice found the collaboration benefits in one place only: “Collaboration benefits came from the few organizations where specs pass between developers and team members employed in roles besides software development.” In developer-only teams, “the benefit was modest: specs became one more artifact to read during review.” And in public repositories, specs are rarely shared work: “98.3% of spec files with a recorded history have a single author” (Agarwal et al., 2026, preprint).

The case for doing it as a team is mostly about review. One commenter: “teammates can push back on a 30-line plan in five minutes, but a 2k-line diff takes an afternoon” (Hacker News, 2026). Microsoft’s training for Spec Kit puts it the same way: “Reviewing a 200-line spec is faster than reviewing a 2,000-line implementation” (Microsoft Learn, vendor).

Who writes, who reviews, who approves

The developer’s line comes from Microsoft’s guidance: “One developer owns the spec and is responsible for keeping it accurate.” Practitioners describe the same split. One commenter suggests that one developer drafts a high-level document with the agent, “and then have the team PR review it” before any implementation starts (Hacker News, 2026). Another team reviews the spec with a first build in hand: “We generate an AI branch immediately every time a spec is completed. It then gets a brief review in our team meetings when the spec is introduced” (Hacker News, 2026).

Why the developer’s review alone is not enough, and what a reviewer outside development should check, is in who reviews the spec and spec-driven development for product managers.

Specs in git: branches, commits and merges

Microsoft’s training gives the most concrete workflow for a team using Spec Kit: “Create a dedicated feature branch for each specification”, commit the spec and have the team review it, then the plan, then the tasks, then build task by task and open a pull request. When requirements change during the build, update the spec first, and “Commit the updated artifacts separately from code changes to maintain clarity about what changed and why.”

What the guidance does not cover is two people writing specs that disagree. One commenter: “I see so many engineers at my company constantly write new specs causing conflicting specs sometimes” (Hacker News, 2025). And a spec agreed once can still drift in conversation: “it changes bit by bit in every meeting and before you know your specs are not aligned with general consensus in the team” (Hacker News, 2026). Three habits help:

• One spec per change, one owner, named in the spec.
• Current specs per area of the system, changed through proposals that the area’s owner approves — OpenSpec’s model; see spec-first, spec-anchored, spec-as-source.
• Decisions written down when they are made, not remembered from the meeting — a line in the decision log.

What git records about a spec, and what it does not, is in requirements in git.

Many people, many agents, one spec

The most detailed team account so far comes from a Thoughtworks exercise. “The 10 engineers were given the goal of building an airline IROps system”, the system airlines use to recover when flights are disrupted. “We managed to build one in four days.” What made it work, partly by accident: “All agents were working off the same spec using the same numbered and identified sections.” Each agent’s plan was linked to sections of the spec and committed as work progressed, so agents could see each other’s progress and integration points (Giles Edwards-Alexander, martinfowler.com, September 2026). It was a practice exercise, not a client project, and the constant commits overloaded the build pipeline, so the team backed off.

The lesson that carries: number the sections of a shared spec, and have every plan and task name the section it serves. Then people and agents can see who is working on what, and a change to a section shows which work it touches.

Across repositories

Most spec tools keep specs next to the code, in one repository. Hari Krishnan’s question on InfoQ: “When your feature requires changes across six different repositories, where does the spec live?” His proposal splits the spec by audience: the product owner states the intent in the backlog, the architect breaks the feature into one sub-issue per repository, still in the backlog, and developers detail the tasks in each repository (InfoQ, February 2026). One Spec Kit user went the other way: “I’m about to move the whole spec folder to its own repository to better handle cross repo work that’s currently painful” (r/ClaudeCode, 2026).

Either way, name one place as the record for each spec, and make the others link to it. How that works with a tracker is in requirements in Jira.

Spec-driven development in Scrum

The few teams that report running both describe a small change. One commenter on r/agile: “We didn’t change the Scrum ceremonies much. The biggest change was that refinement focused more on validating assumptions in the spec than decomposing requirements from scratch.” And: “I’ve seen it work, but only when the spec was treated as a living artifact rather than a handoff document” (r/agile, 2026).

Two limits practitioners put on it. On time: “My rule is no more than one day doing specs before building”, from a commenter who does spec-driven AI development “in an XP approach with Codex” (r/agile, 2026). On size, in SAFe: “writing a spec on ART/Feature-Level is waste. So they exist on Team/Story-Level” (r/agile, 2026). Others find sprints a poor fit: one commenter, at an enterprise software company, finds that working with agents “lends itself more to a flow-based structure (like kanban)” (Hacker News, 2026).

The objections

You learn during the build. Kent Beck’s objection to the descriptions of spec-driven development he had seen: “This encodes the (to me bizarre) assumption that you aren’t going to learn anything during implementation that would change the specification” (martinfowler.com, January 2026). The answer that works in teams is small specs that change when the build teaches something — not a document frozen at the start of the sprint.

Process costs more when building is fast. Marc Brooker of AWS: “Probably the biggest thing that’s changing is the multiplier of overhead of process goes up.” If building takes half the time, the meetings and approvals around it take a larger share of the week (SE Radio 710, March 2026). Every review step has to earn its place.

It becomes a contract again. “Spec-driven development takes you back towards the contractual/transaction model” (r/agile, 2026). That happens when a spec is handed over instead of discussed. InfoQ’s name for the result is “SpecFall” — “the equivalent of ‘Scrumerfall’”.

Rolling it out

1. Start with one team and one kind of change — new features, where most specs are written anyway. One commenter’s advice on experimenting: “My hunch is to experiment not as a team but individually. With teams you want a bit more stability in terms of workflows” (Hacker News, 2026).
2. Decide who reviews and who approves, by kind of change, before the first spec.
3. Decide what happens to specs after the merge — kept current or archived.
4. Name one place as the record for specs, and link the tracker to it.
5. Timebox the spec, and keep it to one story or one change.
6. Look at rework after a few sprints: did fewer changes come back after review?

Hari Krishnan’s summary: “SDD adoption is an organizational capability to develop, not just a technical practice to install.”

Where Specroot fits

This is the problem Specroot works on: a spec a whole team can work from — product, developers, testers and the client — with who wrote, reviewed and approved each change kept with it. Specroot for teams using AI coding agents.