Work Estimation

Estimates are communication tools, not promises. The goal is shared understanding of scope and risk, not precision.

Step 1: Break Down

Decompose the work into tasks where each task is:

• Independently deliverable - produces a testable result
• Small enough to reason about - if you can't explain what it takes, it's too big
• Clear on "done" - you know when it's finished

Task Template

TASK: [what]
DEPENDS ON: [other tasks, or "none"]
COMPLEXITY: S / M / L / XL
UNKNOWNS: [what you don't know yet]
DONE WHEN: [specific, verifiable condition]

Size Guide

Size	Meaning	Typical Scope
S	Well-understood, straightforward	Single file change, clear pattern to follow
M	Some decisions, moderate scope	New endpoint, new component, new test suite
L	Significant scope, some unknowns	New system/module, integration, refactor
XL	Many unknowns, cross-cutting	New architecture, platform migration, multi-team

Step 2: Identify Risks

Risk Type	Signal	Impact
Unknown-unknowns	"I think this should work"	2-5x estimate
External dependency	Waiting on another team, API, approval	Blocked time
First-time technology	Team hasn't used this before	Learning curve
Unclear requirements	"We'll figure it out as we go"	Rework
Integration complexity	Multiple systems need to change together	Coordination overhead

Step 3: Map Dependencies

[Task A] ─── no deps ──→ can start immediately
[Task B] ─── depends on A ──→ blocked until A done
[Task C] ─── no deps ──→ can start immediately (parallel with A)
[Task D] ─── depends on B + C ──→ blocked until both done

Identify the critical path - the longest chain of dependent tasks. That's your minimum timeline.

Step 4: Flag What You Don't Know

The most important part of an estimate is what's NOT included:

EXCLUDED FROM ESTIMATE:
- [assumption that might be wrong]
- [scope that's unclear]
- [external dependency timeline]
- [testing/QA time if not included]

Output Format

## [Feature/Project Name]

### Tasks
| # | Task | Size | Depends On | Risk |
|---|------|------|-----------|------|
| 1 | [task] | S | - | - |
| 2 | [task] | M | 1 | [risk] |
| 3 | [task] | L | - | [risk] |

### Critical Path
[task 1] → [task 2] → [task 4]

### Risks
- [risk] - [mitigation]

### Assumptions
- [assumption that affects the estimate]

### Not Included
- [explicit exclusion]

Anti-Patterns

• Padding instead of breaking down: If you need 3x buffer, you don't understand the work yet. Break it down further.
• Estimating without looking at the code: Read the relevant code first.
• Anchoring on the happy path: Include time for edge cases, testing, review, and deployment.
• Estimating someone else's work: The person doing the work should estimate it.