Task
A task is one day of the technical work inside a story, the card an engineer picks up Monday morning. The Task & Sub-task Writing Guide teaches the craft. Here are the blank card, the blank checklist that rides inside it, and one card filled out end to end.
Copy both blanks into whatever your team plans work in, and use them for every task you write.
The task template
Task Title
[Action] [Component/Feature] or [Technical Deliverable]
Examples: "Implement pay-link generation service" / "Add integration tests for the reminder flow"
Description
[Four parts, in order:]
What
[The specific technical work to be done]
Why
[How this contributes to the parent story]
Technical Details
- [Key implementation points]
- [Technologies or patterns to use]
- [Constraints that matter]
Acceptance Criteria
- [Specific technical requirements]
- [Performance criteria]
- [Test coverage requirements]
Estimates
- Original Estimate
- X hours
- Time Remaining
- Y hours
- Time Logged
- Z hours
Every one of those fields is there because leaving it blank costs somebody else a morning.
One note on the estimate block, because it looks like bookkeeping and usually gets treated that way. I only ever run one comparison on it. When logged plus remaining grows past the original estimate, the card is slipping, and the board is saying so out loud before anyone has to walk over and ask how it's going.
The sub-task template
Sub-task Title
[Verb] [Specific Item]
Examples: "Configure credentials in environment" / "Write unit test for link expiry" / "Update API documentation"
Checklist Format
- Sub-task title (1h)
- Next sub-task (1.5h)
- Final sub-task (2h)
The brevity is deliberate. A sub-task only needs a title and an estimate to do its job. If yours needs a description and acceptance criteria of its own, it isn't a sub-task, it's a task. Promote it and give it the full card.
Sizing rules of thumb
The rough bands I give my teams, meant for calibration rather than science. If your estimate lands outside one of them, that's not automatically wrong. It just means you should look at the card one more time. Ex: a UI component you've scoped at nine hours. The band says two to three, so either the component is bigger than you understood it to be, or what you're really holding is three cards under one title.
- Development. Simple work like an API endpoint or a UI component runs 2-3 hours, medium work like an integration or a piece of complex logic runs 4-5 hours, and complex work like system design or a migration runs 6-8 hours.
- Testing. Unit tests run 1-2 hours per module, integration tests run 2-4 hours per flow, and end-to-end tests run 3-4 hours per user journey.
- Infrastructure. Configuration runs 1-2 hours, deployment setup runs 3-4 hours, and monitoring runs 2-3 hours.
Nothing on the list reaches past eight hours, and that isn't an oversight. Anything bigger isn't a task anymore, so break it down until it is one again. The one-to-two-hour items usually ride along as sub-tasks inside a bigger card, and they only earn a card of their own when they stand by themselves.
When you're forced to break work into smaller chunks, it helps you not only with planning, but also increases confidence in its ability to be completed. The more you break things down and the more questions you ask, the better your planning will be. It's like running a 5 Whys exercise, where around the 5th Why you understand the root cause of why a problem happened. The same happens here. The more you break it down, the better you understand exactly what needs to get done. Whether that's new code, where changes will happen in existing code, or how the new code integrates with the current system.
The card, filled
One task out of the invoicing case you've been following since the worked example. A customer pays an overdue invoice straight from the reminder email, one click instead of a login and three screens. If you read the writing guide, you've already watched this card get built; here it is sitting inside the blanks, the way it would sit in your tracker. The hours are made up to show the sizing, not real numbers off a real sprint.
Task Title
Implement secure pay-link generation and lookup
Description
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 parent story fails at its first step.
Technical Details
- Links expire
- An already-paid invoice resolves to a paid confirmation, not a payment form
Acceptance Criteria
- Every link resolves to exactly one invoice
- Expired and already-paid cases handled
- The edge cases covered by tests
Estimates
- Original Estimate
- 7 hours
- Time Remaining
- 7 hours
- Time Logged
- 0 hours
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, and that number isn't a separate guess sitting on top of the work. It's the five sub-tasks underneath it added up, and you can check the arithmetic yourself. Every heading is filled, and there's nothing about the work hiding somewhere outside the card where you'd have to go looking for it.
Copy them in
Copy both blanks into your tracker today and write tomorrow's tasks in them. The checklist rides inside the task card, so add a Sub-tasks heading at the bottom of the description, or use your tracker's built-in sub-task field if it has one. If a card won't fill all four headings, it isn't ready for the board yet, and the honest move is to leave it off until it is. And when your cards keep coming out wrong, that's a craft problem, and the writing guide is where that gets fixed.
The line on that filled card, "an already-paid invoice resolves to a paid confirmation, not a payment form," comes back on the bug page, where a report gets filed against that exact expectation. Watching the chain hand it down, story to task to the defect that slips through, is the whole argument for writing the cards in the first place.