How to write a chapter

Run the two-question test before writing it

Question one: if this shipped alone, could a user do something new?

If yes it is a story, product owns it, take it back. Question two: do the parent story's acceptance criteria fail without it? If they pass regardless, it is not a chapter, it is tech debt or a bug, and it links to the quarter's Tech Debt or Bug Budget epic. Only work that is invisible to the user and required for the story to pass is a chapter. A migration, an idempotency key, a flag wiring change: chapters. A new screen, a new field, a new email: stories, however small.

Split at the keyboard, not in refinement

Create chapters when the code has told you something refinement could not: a service returns stale data, a migration has to run before the endpoint changes, a dependency needs versioning first. If you can list the chapters before anyone opens the editor, you have not found chapters, you have found a story that is too big. Take it back, split it into stories that each change something a user can see, and get product approval on each one. Chapters written in advance become a private backlog nobody outside the team ever reads.

Cut along seams, cap the count at four

Split where the system already has a joint: a schema change, a service boundary, a contract between two components, a feature flag.

Each chapter should merge on its own behind the parent's flag, so one pull request is one chapter and a colleague can judge it without waiting for the next. Half a day to two days each. If a chapter will not fit in two days, do not nest another level, because there is no level below chapter. Move the seam instead. If you need more than about four, the story was several stories and belongs back with product.

Write five fields and stop

Title: a verb plus the thing, for example "Make the renewal accept endpoint idempotent".

Parent story: one link, nothing else. What changes: the files, services or tables affected. How you will know: the test or check that proves it, an engineering check rather than a product criterion. Out of scope: the neighbouring work you are deliberately not doing here. Under two hundred words in total. Never name a chapter "Part 1 of 3", and never split by backend and frontend out of reflex: neither tells a reader what is left, and neither half can be reviewed alone.

Sequence by dependency, keep one in progress

Order chapters by what unblocks what, and put schema and contract changes first so the later ones build on a settled shape.

Keep exactly one in progress. Three chapters running in parallel across two developers finishes the story later than one developer taking them in order, because the merges fight each other and the review queue backs up. Chapters run the same phases as everything else: todo, in progress, in review, done. If a later chapter turns out to be unnecessary once the earlier ones land, close it with the reason rather than deleting it.

Close chapters on engineering, the story on product

A chapter is done when its own check passes and a human has reviewed the change.

That is the whole bar: no currency figure, no product approval, no acceptance criteria of its own, because the epic already carries the value and the story already carries the criteria. Copying either downwards double-counts the value and gives you two competing versions of done. The story moves to in review only once every chapter is closed and its acceptance criteria are demonstrated end to end, not inferred from three green chapters. Chapters do not release, and value monitoring is for epics.

Take the split to refinement, not the points

Refinement re-points work whose understanding has shifted, but not a story already in flight: that story keeps the size it started with, so cycle time stays honest and your p50 and p85 forecasts keep meaning something. Bring the split to the next fortnightly refinement instead and say two things: what the story looked like going in, and what it turned out to contain. Two or three of these a quarter is normal. The same shape every fortnight, always around the same service or the same kind of change, is a sizing signal to act on.