Task & Sub-task Writing Guide — The Product Playbook

The last page ended with an instruction: break each story into work one person can finish in a day. That unit is a task, the bottom of the hierarchy you've been writing your way down since the epic. The ladder, in one line: an epic is a big outcome, a story is a single slice of it a builder can pick up and ship, and a task is one day of the work inside a story.

A task is the technical work needed to complete a story. One specific deliverable, one owner, two to eight hours, which is to say roughly a working day. And underneath a task sit sub-tasks: one-to-two-hour steps that work like a checklist, not like cards of their own.

One naming note before the craft, because tools disagree about these words. In some setups, including parts of my own templates, a story's children are just called sub-tasks and there's no separate "task" tier at all. Don't fight your tool over vocabulary. I've used Jira and JPD (Jira Product Discovery) for years, and I still haven't found a tool that manages discovery and delivery the way they should be managed. So the grain is the point, not the label: day-sized pieces of work with hour-sized steps inside them. For the rest of this page, "task" is the day-sized piece and "sub-task" is the hour-sized step inside it. Call them whatever your board calls them; the day-sized unit is what matters, not what your tool labels it.

Why a day

You met the one-day rule on the Agile page: the 26-person team where no task could be designed to run bigger than a day, so stuck work surfaced in one morning instead of five. The full story lives there. What that page didn't have room for: writing tasks that fit inside a day is a skill, and it's harder than it sounds.

The problem the rule solves is human, not technical. People early in their careers will spend far more time trying to crack a problem alone than they'll spend asking someone for help. They were hired to prove they can do the job, so when a task goes sideways they research and google and research and google, for days, before they raise a hand. Before the rule, we knew this was happening and tried to manage around it. We checked in on day one of a task. We changed how stand-up ran, hoping stuck work would surface there. Nothing actually worked. You can't process-tweak your way around someone protecting their pride.

The only thing that worked was changing the work itself. When no task is bigger than a day, nobody has to confess to being stuck. The board confesses for them, by tomorrow's stand-up at the latest, and pairing a senior onto the problem becomes routine instead of rescue.

But the rule and the skill are two different things. It took us real time to learn to design tasks that fit inside a day. It was a learning process for the whole team, and until we got there, the rule was just a sentence on a wall. Saying "one day" costs nothing. Writing to it is a craft, and the craft is the rest of this page.

What makes a good task

Five tests:

Specific. One clear technical deliverable. "Build the lookup that resolves a pay link to its invoice," not "do backend work."
Owned by one person. If it needs two people, it's two tasks, or it isn't broken down yet.
Day-sized. Two to eight hours. The eight is a ceiling, not a target.
Testable. There's a way to prove it's done that isn't "trust me."
Independent. Minimal blocking dependencies, so it doesn't sit in a queue behind someone else's work. A natural order inside a story is fine, tests come after the thing they test, but a task that can't start until someone else finishes their day is a task that will sit idle. That's the dependency to design out.

The title carries the deliverable: an action plus a component. Then the description does four jobs, in order. Use them as labeled fields or run them inline in a paragraph, whatever your card supports. What matters is that all four show up.

What: the specific technical work. Why: how it serves the parent story, so the builder knows what they're protecting when they make judgment calls. Technical details: the constraints that are genuinely fixed, not your preferences. Acceptance criteria: the conditions that prove it's done. The technical requirements, the performance bar, the test coverage.

It's the same discipline as the story, one level down. The why travels with the work, all the way to the bottom.

What makes a good sub-task

A sub-task isn't a smaller card. It's a checkbox. One to two hours, concrete, usually done in order, and its whole job is making progress visible inside the day. The title is a verb and a specific item: "Implement the link lookup." "Write unit tests for expiry handling." "Update the API doc." Most sub-tasks need nothing more than a title and an estimate.

Keep them between three and seven per task. A short task, two to four hours, usually doesn't need them at all. The band is for the day-sized ones. More than seven and you've sliced too thin.

The four ways tasks go wrong

The monster task. "Build the entire payment flow." Twenty hours. That's not a task, it's a story hiding from planning, and it's exactly the card that's stuck on day four with nobody knowing. Break it down until every piece fits in a day.
The vague task. "Fix bugs." Estimate that. You can't size what you can't see. Name which bugs and what fixed looks like.
The hidden work. "Create API endpoint, 2 hours." And the endpoint is two hours. The tests are two more. The docs, the deployment, the code review: none of them made the estimate, all of them are real, and the task quietly doubles. Estimate the work, not the typing. Include testing time. Include review time. Estimate conservatively, because an optimistic estimate isn't ambition, it's a surprise you scheduled for later.
The micro sub-task. "Open IDE, five minutes." Now the checklist is theater. Combine steps into chunks that mean something.

The monster and the vague task fail loudly, in planning, where they're cheap to catch. The hidden work fails quietly mid-sprint, when the task is half done and the estimate is already spent. Hunt for the hidden work hardest.

The story from last page, broken down

Take the pay-link story from the Story Writing Guide: a customer pays an overdue invoice straight from the reminder email, one click instead of a login and three screens. This one's a full three-day story, near the top of the story-sized range, so cut at this page's grain it becomes something like four tasks. This is the same business-to-business invoicing case you've been following since Part 04; the hour estimates are made up to show the sizing, not real numbers from a real sprint.

Build the secure pay link: generate a unique link per invoice and resolve it back to the right one (a day)
Build the payment page the link lands on, including the failure and retry states (a day)
Add the link to the reminder email template (half a day)
Integration tests across the whole click-to-paid flow (half a day)

Now open the first one up.

Task: Implement secure pay-link generation and lookup.

What: generate a unique, expiring link for each overdue invoice, and resolve an incoming link to its exact invoice. Why: this is the click in "one click"; if the link is wrong or guessable, the story fails at its first step. Technical details: links expire, and an already-paid invoice resolves to a paid confirmation instead of a payment form. That last constraint came straight down from the story's acceptance criteria. Acceptance criteria: every link resolves to exactly one invoice; expired and paid cases handled; the edge cases covered by tests.

Sub-tasks:

Define the link format and expiry rules (1h)
Implement link generation per invoice (1.5h)
Implement the lookup and resolution (1.5h)
Handle the expired and already-paid cases (1h)
Write the unit tests and update the API doc (2h)

Seven hours. Inside a day, with the tests and the docs sitting in the estimate instead of hiding outside it. And at tomorrow's stand-up, the board shows exactly which checkbox the work is parked on.

"This is micromanagement with extra steps"

Say it. Tasks sized to a day, sub-tasks sized to an hour, status updated every morning. It sounds like surveillance dressed up as process.

It's the opposite, and the distinction matters. Micromanagement usually comes from one place: a lack of trust. And the cure I prescribe to anyone stuck under a micromanaging boss is always the same. Supply them with tons of data about what you're doing, and once you've supplied them with data, supply more. Visibility is how trust gets built.

The one-day grain builds that visibility into the work itself. The board carries the data, every day, without anyone asking for it. Which means nobody has to hover, nobody gets the over-the-shoulder check-in, and nobody spends day four being quietly interrogated about day one's estimate. On my team, pairing happened because a card sat still overnight, not because someone doubted a person. The card got the scrutiny. The person got the help.

Micromanagement is checking on people. This is the work reporting itself, so you never have to.

Keep the card honest

A task card is only useful while it's true. The hygiene that keeps it true:

Update status every morning, before stand-up, not during it.
Flag blockers the moment you hit them. A blocker flagged at 2pm costs an afternoon; a blocker confessed at the demo costs the sprint.
Check off sub-tasks as you finish them. They're the progress signal between stand-ups.
Link the pull requests and commits, the actual code changes and the request to merge them in, to the card, so the work and the record can't drift apart.

And before a task ever reaches the board, one last pass:

One person can own it
Done within a day
Outcome is testable
Dependencies identified
Estimate includes the tests, the docs, and the review

The bottom of the hierarchy

Step back and look at how far the work has traveled. A validated problem became an epic with a finish line. The epic became stories a stranger could build. The stories just became day-sized tasks with hour-sized checkpoints inside them, and the same why is attached at every level. Nothing in the chain has room to hide, and nobody in the chain has to guess.

The number one struggle I've seen, at every company size I've worked, is communication. A task card is delegation in writing. If the engineer builds the wrong thing from your card, that's on you. You don't get to point fingers and say "you didn't do what I said" when the card never said it.

So finish the thread. Take one story and break it down: tasks one person can finish in a day, sub-tasks they can check off by lunch, estimates with the tests and the review already inside. If a piece won't fit in a day, you're not done writing. Cut again.