Implementation Sprint Delivery — Claude Code Guide

Implementation sprint as a short delivery loop

An implementation sprint is not permission to work without limits, but a short delivery interval with one outcome, a bounded set of slices, and a predefined exit. The sprint should turn an approved plan into a reviewable increment, not hide uncertainty behind a calendar label.

Each slice should have an owner, input, expected output, verification, and checkpoint. If a slice turns out to be larger than planned or changes the contract, split it or return to planning rather than quietly adding it to the sprint.

Sprint rhythm

1. State the sprint outcome and non-goals in terms of observable behavior.
2. Break the outcome into small slices with sequence and stop conditions.
3. At each checkpoint, inspect the diff, targeted signals, and remaining Unknowns.
4. End the sprint with one of these decisions: DONE, CONTINUE WITH APPROVAL, or HOLD.
5. Update the evidence/handoff record even when the result is HOLD.

Sprint plan

# IMPLEMENTATION_SPRINT_PLAN.md
Outcome: one reviewable capstone slice
Slices: contract -> implementation -> targeted verification -> review
Checkpoint: inspect diff and command status after each slice
Owner: <role>
Exit: acceptance met, evidence linked, or HOLD with reason
Deferred: unrelated cleanup and unverified integrations
Status: documented example; sprint execution: Unknown.