The ticket said "build notifications system." Three weeks later, it's still in progress. Nobody knows how much is left. The engineer keeps finding new edge cases. Every standup is the same update: "still working on it."
This is what poor task breakdown looks like - vague tasks that never end and work that has to be redone because assumptions were wrong. Not to mention surprises in the final week that should have surfaced on day one and three people working on the same thing because ownership was unclear.
The work itself isn't hard. The breakdown was botched.
Starting off right
Task breakdown presupposes you've already done the hard work: defining where you are with brutal honesty and where you're going with obsessive clarity on the "why." If you skip this, no amount of clever task management will save you. The tasks will be wrong because the inputs were wrong.
If you haven't nailed these down yet, check out my post on ABDiff. Come back when you have a clear starting point and destination. You can't subtask properly unless this is done.
Deriving the tasks
Once clarity on where you're at and where you're going is achieved, the task list writes itself. This is the mechanical part.
The level of detail depends on who's consuming the breakdown. A director's task list looks different from a tech lead's. Tasks should be at the granularity the next layer down needs to execute without ambiguity.
This can feel slow. An hour spent here saves weeks of confusion later. The initiative that drags on forever usually skipped defining tasks with clarity.
Here's what works well for us.
Steps for breaking down projects into tasks
- Work backwards from the destination. Start at the end. What's the last step? Then what comes before that? Keep doing this until you reach where you are today.
- Define "done". Each ticket should have a clear set of criteria to know whether it is officially completed. Don't mark tickets as done if testing or approval is required, this will throw off progress tracking and key quality checks will fall through the cracks.
- Build the tickets to make progress tracking easy. How will you know it's moving? Where do you check? Structure work so progress is visible without status meetings. Sub-tasking isn't just for others to know what there is to do - its for leadership to know what's left.
- Identify dependencies and blockers. What has to be true before other work can start? Surface these early.
- Timebox uncertainty. Don't know how long something takes? That's a spike with a fixed timebox. The output is a decision, estimate, and sometimes more tasks, not code.
- Make tasks independently shippable. Each task delivers something complete and creates natural checkpoints. This also prevents the project from being perpetually half broken.
- Assign owners. Each task has a person responsible for its completion. If no single person is assigned, you're assigned.
- Run a pre-mortem. Imagine the project failed. What went wrong? Turn each failure mode into a task that de-risks it early. Problems found now are cheap. Don't be proven a fool later.
- Be painfully thorough. Your backlog should always be comprehensive of the work needed to complete the project.
Example ticket template
The goal is to set up the implementer for success without drowning them in process. Include enough that they can start confidently and complete independently.
The litmus test: could a person without as much experience or context as you pick this up and know both what success looks like and why it matters? If no, continue writing.
Always err on the side of greater clarity. If you don't put in effort here, you'll end up spending more time clarifying later and cleaning up the mess caused by your ambiguity.
Here's a template that works for us, but build one that works for you.
## [Brief title]
**Owner:** [Name]
### Why this matters[One or two sentences on why we're doing this. Gives the implementer context to make tradeoffs without escalating.]
### What "done" looks like[Describe the outcome as observable behavior. "User sees confirmation message after submitting" beats "function returns true on success."]
### Context- [Link to design doc]- [Link to related ticket]
### Gotchas- [The legacy system that can't handle nulls]- [The vendor API that rate limits aggressively]- [The edge case that broke production last time]Find what works for your team
The exact framework matters less than you think. Scrum, Kanban, shape up, something homegrown - they all work if you do the fundamentals right and keep disciplined. They all fail if you don't.
What matters is that work gets done and problems surface early. If your current process achieves that, great. If it doesn't, change it. Don't waste time arguing over ticket templates or sprint lengths or estimation techniques. Those debates feel productive but rarely are.
Try something. See if it helps you ship and catch problems sooner. Frequently retrospect. Keep what works. Drop what doesn't. That's the whole game.
The task list is the easy part
The initiative that balloons does so because nobody agreed on where they started or where they were going. Do the hard work upfront to define those clearly. After that, the task list writes itself.
Break things down small. Make progress visible. Keep the "done" bar clear. The rest is execution.
