How to write a chapter (a sub-task of a story)

No. Chapters are the last level. A chapter you cannot finish in two days is telling you the seam is in the wrong place, or that the parent should have been more than one story. Move the seam first, and if that does not work, stop and take the story back to product rather than inventing a level below.

No. Points stay on the parent story, and that story keeps the size it was given before the build started. Size chapters in days, for sequencing only, and never sum those days back onto the story. The moment chapter sizes feed your velocity, the throughput data that produces your p50 and p85 stops being comparable across quarters.

No. The developer creates and closes them, and they should still be visible on the board so the chain from chapter to story to epic to outcome holds. If product is being asked to make a call on a chapter, whatever is under discussion is user-visible and should have been raised as a story.

Convert it. Raise it as a story under the same epic, get product approval, and let product decide whether it belongs in this quarter or the next. Do not ship a user-visible change under a chapter because the branch and the flag happen to be there already, which is exactly how work disappears from the board product reads.

A chapter is The Tenhaw Way's name for a sub-task, the fourth and optional level of the breakdown, below the outcome, the epic and the story. A developer creates chapters mid-build, once a story turns out to be bigger than refinement thought. A chapter carries no currency value, no product approval and no user-visible slice, because the story above it holds all three. A good one names one technical deliverable, merges on its own behind the parent story's flag, and takes half a day to two days, about four per story at most. Chapters exist so a big story stays visible and reviewable, not so it stays hidden. Tenhaw publishes the whole method, these rules included, free to adopt without hiring us.

Split it mid-build along the system's existing seams: a schema change, a service boundary, a contract between two components, a feature flag. Each sub-task should name one technical deliverable, merge on its own behind the parent story's flag, and take between half a day and two days, with no more than about four in total. Do not nest a level below; if a piece will not fit in two days, move the seam instead. And keep the split invisible to the user. Anything a user could see when shipped alone is a new story that needs product approval, not a sub-task.

A story changes something a user can see and needs product approval; a sub-task is invisible to the user and exists only so the story's acceptance criteria can pass. Two questions settle it. If the work shipped alone, could a user do something new? If yes it is a story. A new screen, a new field or a new email all qualify, however small. Do the parent story's acceptance criteria fail without it? If they pass regardless, it is not a sub-task either, it is tech debt or a bug and belongs against those budget epics. A genuine sub-task, like a migration or an idempotency key, is invisible to the user and something the criteria cannot pass without.

During development. Create sub-tasks when the code has told you something planning could not: a service returns stale data, a migration has to run before an endpoint changes, a dependency needs versioning first. If you can list the sub-tasks before anyone opens the editor, you have not found sub-tasks, 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. Sub-tasks written in advance read as diligence, but they are a sizing failure in disguise, and they become a private backlog nobody outside the team ever reads.

In sequence, with exactly one in progress at a time. Order them by what unblocks what, putting schema and contract changes first so later work builds on a settled shape. Three sub-tasks 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. Each sub-task should be one pull request that merges on its own behind the parent story's flag, so a colleague can review it without waiting for the next. If a later one becomes unnecessary once earlier work lands, close it with the reason rather than deleting it.

Only if the story's acceptance criteria fail without it. A genuine sub-task is work the story cannot pass without, and that is the whole test. A refactor the criteria do not depend on belongs against the quarter's Tech Debt epic instead, raised properly rather than buried under a story because raising it takes longer. Those budget epics exist so the quarter's burn rate stays visible, and every item hidden under a story makes that number a lie. Defects you trip over mid-build follow the same rule. If the story's criteria pass regardless, they are raised against the Bug Budget epic, not slipped in as a sub-task.

No, and it is the split that most often defeats the point of splitting. Backend and frontend are two halves of one change. The reviewer cannot judge either half without the other, and nobody reading the board can tell what is actually left. A sub-task has to stand up on its own, one pull request that merges behind the parent story's flag, so cut at a joint the system already has instead. Names like Part 1 of 3 fail the same test, because they describe the order somebody happened to work in rather than what the work is.

Five fields, and stop, in under two hundred words in total. A title that is a verb plus the thing, such as Make the renewal accept endpoint idempotent. One link to the parent story, 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. And out of scope: the neighbouring work you are deliberately not doing here. Anything beyond that is either restating the story above it or hiding a second sub-task inside this one.

It costs about an hour, once, on the story that surprised you. Four sub-tasks at most, five short fields each, under two hundred words in total, written at the keyboard by the developer who found the problem. Tenhaw's engineers work that way on client delivery, against a published standard of 72 rules written to be enforced by an agent. Set that against the alternative, where a story sized at two days quietly takes four, one large pull request lands at the end, and until it does nobody outside the team can see what is left or review any of it in pieces. The admin is not the split. It is what you pay when a big story stays hidden instead of staying visible and reviewable.

No. A sub-task closes on engineering when its own check passes and a human has reviewed the change. The story moves to in review only once every sub-task is closed and its acceptance criteria are demonstrated end to end, not inferred from three green sub-tasks in a row. That gap is where defects live, because each piece was verified against its own technical check and never against what the user was actually promised. Sub-tasks do not release either, and value monitoring stays at epic level, where the currency target sits.

Two or three times a quarter is normal, and it deserves one line at the next fortnightly refinement rather than a post-mortem, covering what the story looked like going in and what it turned out to contain. The pattern is what matters. The same shape every fortnight, always around the same service or the same kind of change, is a sizing signal to act on. Tenhaw watches that rate on client delivery, the same attention to flow that cut delivery lead times by 60% within six months at Globelynx. At that refinement, resist re-pointing a story already in flight to tidy the burn-down, because it corrupts the throughput history your p50 and p85 forecasts are built on.

Because the value is already held above it, and putting a number on the sub-task counts it twice. Tenhaw reports the money at outcome and epic level for the same reason. The epic carries the planned share of the outcome in currency and the story carries the acceptance criteria, so a sub-task with its own figure appears a second time when somebody sums the quarter, and the roadmap starts claiming more value than the outcome was ever priced at. Giving one its own product acceptance does the same damage in a different direction. You end up with two competing versions of done, and a developer choosing between them mid-build.

Do not roll them out as a process. A sub-task is what a developer writes at the keyboard, once the code has told them something refinement could not, so the habits matter more than the tooling: create one only mid-build; cap them at about four per story, half a day to two days each; keep exactly one in progress; give each five fields and no currency value; and report the split in a line at the next refinement without re-pointing a story already in flight. Tenhaw calls them chapters and passes habits like these on by pairing with a client's own engineers. The name matters less than the rules. Run it for a quarter and your real sizing problems surface on their own.