A spec per run, or a sprint?

Every tool in this category has a unit of work. That choice decides more than it looks like it does.

The common shape is one ticket at a time: you describe a change, the agent writes a spec, plans it, breaks it into tasks and builds it. Ship it, then start again from an empty page.

SDLC Studio’s unit is a sprint: a prioritised batch of work, driven to a goal, reviewed at its boundary, and closed with a retrospective that has to produce something. The batch is the thing you plan, the thing you review, the thing you learn from.

Why the unit is the whole argument

This is not a preference. It is where the discipline pays for itself.

SDLC Studio’s own published measurements say that on one small, well-specified change, the full pipeline costs around 3.1x the tokens of just asking the model, and buys little. That is an uncomfortable number to publish, and it is the honest one. The value shows up in the fan-out: one planning structure driving many units, with the fixed costs spread across everything delivered under it while the per-unit defect protection repeats.

A tool whose unit is one ticket is permanently in the regime where the overhead does not pay. It cannot amortise, because it has nothing to amortise across.

Five things you cannot do with a batch of one

1. Review at a boundary

A batch of one has no boundary between delivery and close - they are the same instant. So every finding a review makes arrives after the work is nominally finished. It is repaired fast and late, by whoever is still holding the context, in the code that most needs care.

One measured run here delivered in five hours and took six and a half hours to close. Only about 18% of that was gate and test time. The rest was repair generated by a review that ran too late to be cheap.

That is why the adversarial review runs at the batch boundary. Reviewed there, a finding is delivery work in the batch that caused it, priced against that batch, and fixed by a context still holding it.

2. Fan out across parallel lanes

Parallel delivery is offered only when the batch splits into two or more file-disjoint groups. The planner’s own contract puts it plainly: a one-unit batch is delivered sequentially. Fan-out is unavailable below batch size two - not by policy, but because there is nothing to fan out.

3. Prioritise

WSJF - cost of delay over job size - is a ranking function. A set of one has exactly one ordering. Point a per-ticket tool at your backlog and the prioritisation decision has already been made, by whoever typed the ticket. Sprint planning ranks the batch and tells you what it chose and why.

4. Amortise the fixed cost

A run has a fixed cost that has nothing to do with how much work is in it: the planning, the ceremony, the review setup, the close. Fitting this project’s own measured runs gives a marginal cost of roughly 13,000 tokens per story point against a fixed cost of roughly 3.9 million per sprint.

The consequence is counter-intuitive and worth sitting with:

5. See two units contradict each other

The most expensive defects are not inside a change. They are between two changes that were each individually correct. One review here found two units shipping in a single commit that contradicted one another - neither ticket was wrong on its own.

A tool whose widest field of view is one ticket has nowhere to stand to see that. A sprint has shared-file clusters, a whole-batch diff, and a review that covers the set.

And it has somewhere to put things

When a per-ticket run finds something outside its ticket it has two options: do it anyway, unpriced, or drop it silently. A sprint has a third. The finding is filed, ranked, and turns up in the next batch’s ordering. Blocked units are quarantined and named. Decisions you are not ready to make are deferred and asked together, structured, at the stop.

Nothing goes missing quietly, which is a different property from nothing going wrong.

It gets better each sprint

The loop closes. A retrospective is checked on its content, not its existence - a gate that tests for a file is satisfied by touch - and every finding it records is either filed as work or declined with a stated reason. Both are green. What is refused is silence.

The lessons are then lifted out of the retro into a store, because a lesson that stays in the retro file is read by nobody after the sprint that wrote it. The tooling’s own comment on that function is the clearest statement of it: without this the retro is a diary. The next sprint’s plan prints those lessons unasked, including a cross-project registry a brand-new project inherits on day one.

And the estimate calibrates. Every project starts on a shipped default rate; once it has five units of its own measured evidence, its own numbers replace the default. A per-run tool has no denominator - a rate needs points delivered and a sprint to divide by.

Batch-to-goal, not time-boxed

A sprint here closes when its goal is verified, whether that takes an afternoon or a week. Coordination regimes change when the machine does; a fixed-length sprint is local sun time kept after the trains arrived.

The run is one object

A project holds exactly one run at a time, and it is a thing you can inspect and change rather than a train you either ride or abandon.

A batch sharing no unit with the open run is refused, not merged. Folding unrelated work into an open run would leave it with one goal describing a fraction of the work and a closing verdict nobody could give honestly.
An overlapping re-plan - a re-cut, or a sweep pulling blocked work in - accumulates into the same run under its unchanged id. That is the normal way a batch grows.
Every in-flight change is recorded, so the close can say what was actually delivered and why it differs from the plan.

What it costs, honestly

The batch is not free, and the trade is real:

Review convergence cost rises with the batch. A bigger diff carries more surface, more claims and more findings, so it takes more rounds to converge. Review rounds on this project run at 62% REJECT.
Grooming is unpriced work. A freshly refined story arrives with placeholder criteria. Authoring them is real effort and story points do not cover it.
There is no recommended batch size, and we will not invent one. The fixed cost pulls towards larger batches and review convergence pulls towards smaller ones. Both directions are visible in the measured history, the sample is small and noisy, and picking a number off it would invent a target the data cannot defend.

That last one is deliberate. Read your own velocity and decide per batch.

Where to next

Sprint planning - the goal ladder, the breakdown gate, ordering and the appetite.
Delivery - sequential or parallel, and changing a run without lying about it.
Review and close - the batch boundary, the checklist, the retro.
Charters - queueing the runs you have not had yet.
Evidence - every number on this page, with its source and its caveats.