Planning and task breakdown

Overview

Good task breakdown is the difference between a project that ships incrementally and one that delivers a big-bang surprise at the deadline. Tasks must be atomic (one logical unit), verifiable (you can prove it's done), and independent (completable without blocking on other tasks).

When to Use

• After writing a spec, before starting implementation
• When estimating a project
• When coordinating work across multiple engineers
• When a task has been "in progress" for more than 2 days

Process

Step 1: Identify vertical slices

A vertical slice delivers end-to-end value: from input to storage to output. Prefer slices over horizontal layers (don't plan "do all the models, then all the controllers, then all the views").

Step 2: Write tasks in the format: [Verb] [Object] [Constraint]

Good: "Add rate limiting to the /api/search endpoint (max 100 req/min per user)" Bad: "Rate limiting"

Step 3: Apply the two-day rule

No task should take more than 2 days. If it does, break it down further. If it genuinely can't be broken down, flag it as a risk.

Step 4: Define done for each task

Each task must have a clear, observable "done" state: test passes, endpoint returns 200, UI renders without error, migration runs cleanly.

Step 5: Identify dependencies

Draw or list which tasks must complete before others can start. Minimize dependencies — they are schedule risk.

Step 6: Identify the critical path

The longest chain of dependent tasks sets the minimum delivery time. Optimize this chain first.

Step 7: Add a buffer

Add 20% time to estimates for unknowns. If you've never done something before, add 50%.

Step 8: Sequence for early learning

Put the riskiest tasks first. You want to discover impossible requirements on day 2, not day 20.

Anti-Rationalizations

"These tasks are too small to track" If it's too small to track, it's too small to lose track of — which means it will be forgotten. Track it.

"I'll figure out the subtasks as I go" Figuring out subtasks during execution means context-switching between planning mode and execution mode. Do the planning upfront.

"The spec is clear enough — I don't need to break it down" A spec describes the destination. A task breakdown is the map. You need both.

Red Flags

• Tasks without acceptance criteria
• Tasks estimated at "a few hours" that have been open for a week
• All tasks blocked on one person
• No buffer in the plan

Verification Requirements

• Every task has a verb-object-constraint format
• No task is estimated over 2 days
• Every task has a measurable "done" state
• Dependencies are mapped
• Critical path is identified
• 20% buffer included
• Riskiest tasks are sequenced first