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