Sprint planning

A sprint starts by selecting and ordering a batch. You can say it in plain language - “plan the next sprint”, “break it down but don’t write code”, “deliver all the open bugs” - and it maps to the explicit form.

/sdlc-studio sprint --bugs Open --goal done          # deliver the open bugs
/sdlc-studio sprint --crs Proposed --goal design     # just the backlog, no code
/sdlc-studio sprint --epic EP0007 --goal done        # deliver an epic
/sdlc-studio sprint --bugs Open --crs Proposed       # one mixed backlog-clear tranche
/sdlc-studio sprint --bugs Open --autonomous         # unattended, guardrails on

The goal ladder

The goal is a stop-point, and the rungs are cumulative. Ask for a lower rung when you want a checkpoint; ask for done to take it all the way.

--goal	Stops when	You get
triage	the plan is approved	the ordered worklist, and the readiness of the batch
plan	a sprint-sized batch is selected, sequenced and estimated	a committed sprint plan
design	every unit is decomposed to Ready stories with criteria and points	a reviewable, estimated backlog
done	every unit is implemented, verified, conformant and reviewed	the delivered increment

The Sprint Goal

Separately from the rung, a run carries a Sprint Goal: one sentence of product outcome, 20 words or fewer, that unifies the batch. Not a pipeline stage - an outcome. A longer goal is refused at plan.

/sdlc-studio sprint plan --bugs Open --write \
  --sprint-goal "the release blocker list is empty and each fix has a regression test" \
  --serves O2

--serves names the PRD outcome (O2, from the PRD’s ## Outcomes) or the persona the goal serves; repeat it for more than one, or name one as a whole word in the goal. The plan prints goal serves: ..., or goal serves: NONE with what the goal could serve - advice, never a refusal.

It is prompted for when absent and never invented. Before the run opens, the seats read it: is it achievable by this batch, what does done mean for it, and does it read as one increment? What they say is advice printed with the plan. An objection does not refuse the plan and there is no override flag; a goal no seat read is recorded as not read, never as approved.

At the close it is judged: goal-verdict --verdict achieved|partial|missed. A run whose plan set no goal is judged as a batch, honestly. The tooling will not invent alignment after the fact.

The breakdown gate

sprint plan refuses a batch whose units are not groomed. Every unit must declare two things:

Field	Why it is compulsory
Affects:	the files the unit will touch. Without it nothing can size the unit, and nothing can see that two units touch the same file - so the planner reports them as safely parallel when they will collide
Points:	the job size on the modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20). Not urgency, not a guess at hours. It is relative: is this bigger than the last 3 you delivered?

Ungroomed, it exits non-zero and prints no plan at all. This is deliberate - a plan over unsized units cannot be sized or safely parallelised, and it looks authoritative anyway. The refusal names each unit, what it lacks and the fix.

breakdown: 20 unit(s), 15 ungroomed, 0 above 8 points, 4 shared-file cluster(s) (mode=enforce)
  ungroomed - `sprint plan` refuses a batch holding any of these:
    BG0488  lacks: Acceptance Criteria (none at all)
    BG0513  lacks: Acceptance Criteria (restates the summary, so nothing states what passing is)
    ...
  opt out ONLY as a recorded decision. an absent config BLOCKS.

Take the same census read-only, before you commit to anything:

sprint.py breakdown --stories Ready --bugs Open

Note

Opting out is possible and it costs a recorded decision: sprint.breakdown: judgement in .config.yaml makes the lane report instead of block. Omission is not an escape - an absent config blocks.

Above 8 points, refused

A unit above the split threshold is refused and must be split, not estimated. This is not ceremony bolted on; it is the rule that makes the cost model work.

A story point behaves as a stable unit of cost from 2 through 8. When this was measured, in July 2026 (RFC0038), 21 delivered units from four earlier sprints of this repository were re-estimated blind by three estimators, 19 of them with measured actuals. By points band, a point cost 22,370 tokens in the 2-point band, 26,153 in the 3, 27,396 in the 5 and 25,171 in the 8: essentially flat, which gave the flat rate of about 25,000 tokens a point. Individual units scatter round that rate: 12 of the 19 fell within 0.75x-1.25x of it. Those actuals are per-unit build costs, with no review rounds or close in them, so they price the build and not a whole sprint. Above 8 it breaks: the 13-point band came in at 14,144 tokens a point, 1.9x cheaper: the 13s were systematically over-estimated, and every estimator returned them with low confidence and the unprompted words “should be split”. The figures are on the evidence page.

So above 8 the estimate is not worth having, and the honest answer is to decompose - which is a triage decision, not an estimation one. A 7 is refused too: that is the false precision the scale exists to prevent.

Decomposing also makes the estimate better, not just the tracking. Four large requests sized in one shot came in at 0.56x their forecast with a 2.3x spread. Decomposed first, their summed points against the same unchanged rate predicted the batch to 1.00x.

Ordering

/sdlc-studio sprint <batch> --order priority   # default
/sdlc-studio sprint <batch> --order wsjf       # cost of delay over size
/sdlc-studio sprint <batch> --order manual

WSJF is cost of delay divided by job size, with both on the same modified Fibonacci scale. It is seat-scored - sprint planning is a value, size and risk judgement rather than a bare priority sort - and the components are recorded in the plan artefact, so the ordering can be argued with later.

Dependency waves and shared-file clusters

For priority and wsjf, the plan emits waves alongside the flat order: wave 1 is everything with no in-batch dependency, wave n+1 is everything whose dependencies sit in earlier waves. Units inside one wave are independent, and therefore parallelisable.

The planner also derives clusters from the Affects it already parses. A declared dependency is a claim; a shared file is a fact. Units touching the same file are one cluster and are not independent parallel work, whatever the declarations say. Without this the planner once reported two units as safely parallel while both were rewriting the same module.

Capacity and appetite

Three ceilings, set in .config.yaml:

capacity:
  tokens: 500000   # forecast ceiling for the batch
  minutes: 240     # wall-clock ceiling for the run
  units: 8         # unit-count ceiling

The appetite is the circuit breaker built from those. It is resolved once at plan time and stamped on the run, so the ceiling the plan sized the batch against is the ceiling that stops the run. It is never auto-extended. Zero on an axis means unbounded.

Raise it in flight and that is a recorded decision, so the close still reports the overage rather than showing a run that neatly fitted:

sprint.py appetite resize --units 16 --reason "an epic joined the batch"

Tip

Set these from your own measured rows rather than picking round numbers. This project’s ceiling was once so low that every plan reported over budget - at which point the one instrument meant to say “this batch does not fit” had become a constant, and stopped being information.

The forecast

forecast = sum(Points) x tokens-per-point

Cost is points times a measured tokens-per-point rate, re-measured every time a plan is built. The rate is the median of your working model’s latest five rows in VELOCITY.md; short of that, it falls back to the per-unit evidence log and then the shipped seed, and the plan says which one it is quoting. A rate re-fitted to one or two units is fitting noise, and this project has twice had to delete a rate that hardened into an article of faith.

It prices the build, and the plan names what it leaves out: the closing review, repair rounds and re-verification, orchestration, and delegated-agent spend the capture cannot yet see. Where proving dominates, that is most of the total, so the plan also reports the measured whole-sprint multiple of the forecast - read off past sprints, never fitted.

Where to next

• Delivery - what happens once you approve the plan.
• Review and close - the batch boundary and the close chain.
• Configuration - every key named on this page.
• Evidence - the measurements behind the 8-point threshold and the forecast.