Small Batches

Small Batches

Large batches feel efficient and are the opposite: work queues up invisible, risk compounds silently, and feedback arrives only after everything is wrong. From Toyota's lean manufacturing to Ries's startups, the rule is the same — shrink the batch until the cost of finding a mistake approaches zero. This skill audits batch pathology and re-cuts plans into slices that ship and learn.

Why Small Batches Win

The famous envelope-stuffing example: fold, stuff, seal, stamp one envelope at a time looks slower than running each step in bulk. It is not. Small batches finish end-to-end sooner (first feedback arrives at envelope one, not after all hundred), surface defects at the cheapest moment, and keep work-in-progress visible. Big batches hide every problem until the moment it is most expensive.

Modes

Audit mode (default — user pastes a roadmap, epic, backlog, or release plan)

1. Read references/batch-pathologies.md before flagging.
2. Number every item, feature, or workstream.
3. Flag each pathology present: big-bang release (everything ships at once), integration-at-end (pieces merge only when all are done), requirement hoarding (months of specified-but-unbuilt work), done-but-unshipped (work finished, waiting for a batch to join), invisible WIP queue (work started but not completable soon).
4. Measure the batch: time from first work started to first user learning. That number — not story points, not task count — is the batch size that matters.
5. Verdict — "Slicing well" (learning under 2 weeks), "Batching up" (2–6 weeks), "Batch pathology" (6+ weeks or unmeasurable because nothing ships until the end).

Re-slice mode (audit done, user wants the re-cut plan)

1. Find the slice axis: the thinnest path through the work that ships something to a real user and produces learning. Usually vertical — one user, one job, end to end — never horizontal ("the database layer," "all the UI").
2. Re-cut the work into slices. Every slice passes three tests: it ships (deployable on its own), it learns (a real user's behavior changes measurably), and it is smaller than the last one that hurt.
3. Sequence the slices by learning value, riskiest first (the build-measure-learn loop governs the order; the roadmap does not).
4. Write the re-slice from templates/slice-plan.md with the integration and release checkpoint at every slice boundary — the moment work is "done" is the moment it merges, not a date at the end.
5. Name what gets easier to say no to: small batches expose work that no longer needs doing. Killed scope is a re-slice deliverable, not a failure.

Hard Rules

• Batch size is measured in time-to-learning, never in task count.
• A slice that cannot ship alone is not a slice; it is a fragment.
• Integration is continuous or the batch is still big — merging at the end is the pathology wearing a different hat.
• Every slice boundary has a release decision: ship it, or say out loud why not.
• If the plan cannot be sliced without shipping something embarrassing, the slice is still right and the embarrassment is information.

Output Shape (Audit mode)

Followed by the batch measurement, verdict, and the recommended slice axis. Keep output in the user's language. Never re-slice without naming the learning each slice produces.