How to write a chapter
A chapter is what a developer creates when a story turns out to be bigger mid-build. It's a tactical sub-task, not a user-visible slice.
Why it matters
Stories should ideally land in one sprint. When one doesn't, the right move isn't to grow the story, it's to chapter it. Chapters give the team granular flow visibility without polluting the backlog with sub-tasks that have no user value.
Step by step
- Trigger. Mid-build, the story is clearly bigger than it looked. Don't chapter pre-emptively.
- Title is engineering-shaped. "Add Postgres index on jobs.user_id", not pretending to be user-facing.
- Description: what + why, briefly. One paragraph.
- Estimate in points if useful. Chapters can be small (1–2 pts) and that's fine.
- Link to the parent story. Always. Chapters never float.
- Move through the same dev phases. todo → in-progress → in-review → done. But chapters don't get released independently.
What good looks like
- One parent story; never floats
- Engineering-shaped title
- One paragraph of context
- Doesn't try to deliver user value alone
- Closes when the parent story closes
How Tenhaw runs this
Chapters in Tenhaw inherit the parent story's deps and team. They flow through dev phases independently but can't be released on their own. The platform won't let you ship one in isolation.
- Tenhaw Chapters
- Tenhaw parent-story enforcement
In Tenhaw → open the parent story → New chapter. Chapters inherit the story's deps and team automatically.
Run this in your team
The Tenhaw product enforces every rule in this playbook so it doesn't sit on a wiki gathering dust. Try Tenhaw or book a working session with the founder.