Tools · Story Breakdown
One big story.
Many small, shippable ones.
Story Breakdown is a session dedicated to taking large, ambiguous user stories and breaking them down into small, executable engineering tasks. Lincah runs the whole session live in the browser — the PO presents, the team drafts tasks, and everyone leaves knowing exactly what “done” looks like.
Participants join with a display name and a 6-character code — no account required.
Every story splits until each piece is small enough to finish in a day.
Sprint, without Story Breakdown
Day 1, standup
“Build report export end-to-end” — in progress.
Day 4, standup
“Build report export end-to-end” — still in progress.
Day 6, standup
Turns out the DB migration, the async worker, and the UI polling logic were each a day of work on their own. Nobody noticed until the sprint was half gone.
A single vague line item was actually three tasks — nobody found out until it blocked the board.
Why it exists
Ambiguity survives estimation. It doesn't survive a task list.
A story can sound clear in a refinement meeting and still hide a week of surprises. Story Breakdown exists to reduce risk, improve estimation accuracy, and make sure everyone understands the technical implementation details before work begins — not after it's already started.
Writing the actual sub-tasks forces the conversation that estimating alone skips: what does this really touch, and who is doing which part of it.
The ritual
From one story to a done-ready task list.
The mechanics protect one thing: nothing counts as broken down until it's small and specific. Try it on the board to the right — split the oversized task and see why it mattered.
- 01
Present the story
The Product Owner reads a large, ambiguous story to the room — scope, intent, and why it matters now.
- 02
Discuss the architecture
The engineering team talks through how it would actually get built — data model, endpoints, UI surface.
- 03
Draft the sub-tasks
The team writes specific tasks live: “Update DB schema”, “Create API endpoint”, “Build UI component.”
- 04
The PO clarifies, doesn’t prescribe
When a task is unclear, the Product Owner answers “what does done look like?” — not how to build it.
- 05
Attach done-criteria
Every task gets a concrete definition of done before it counts as broken down.
- 06
Check the size
Any task still bigger than a day gets split again. Small enough to finish is the exit condition.
A scripted round — the real one syncs live across every device in the room.
In the room
The lobby, before the session starts.
Everyone lands on the same join screen — the facilitator queues the story, the room joins from their phones, and the projector shows who's in before the breakdown begins.
Facilitator
You queue the story.
Share the join code, watch the team land in the room, then open the story you're about to break down.
Participant
They add tasks from their seat.
A display name and a 6-character code. No account, no install — engineers draft sub-tasks live from whatever device is in front of them.
Broadcaster
The room, on the wall.
A read-only view built for the projector, so everyone sees who's in before the first story gets read out loud.
The spec
When to run it.
- What
- A session dedicated to taking large, ambiguous user stories and breaking them down into small, executable engineering tasks.
- Why
- Reduces risk, improves estimation accuracy, and ensures everyone understands the technical implementation details before work begins.
- When
- During Backlog Refinement, or just-in-time before pulling a story into development.
- Who
- The Development Team and Product Owner.
- Joining
- Participants enter a display name and a 6-character code. No account, no install.
- Plans
- Free and Pro plans available.
Table talk
Field notes from facilitators.
The tool runs the mechanics. These four habits are what keep the tasks small enough to trust.
One day or less, no exceptions.
Break stories until every task takes one day or less — anything larger still carries hidden risk and will block the daily standup.
The team breaks, the PO clarifies.
Engineers define the tasks. The Product Owner’s role is to answer “what does done look like?” — not to prescribe how the work gets built.
No done-criteria, not done breaking down.
“Create API endpoint” is not done-ready. “Create POST /api/tasks endpoint returning 201 with task object” is. Vague tasks are unfinished breakdowns.
Watch for tasks spanning multiple layers.
A task that touches DB, API, and UI together is usually three tasks disguised as one — and the most common source of mid-sprint surprises.
Split the story before it splits your sprint.
Free and Pro plans. Your team joins with a display name and a 6-character code — nothing to install, no accounts for participants, and every task leaves the room with a clear definition of done.