Estimate four components separately: setup + core work + interruption recovery + teardown — omitting any causes 30-60% underestimation

Why This Is a Rule

When you estimate "how long will this coding task take?" your brain simulates the core work: writing the code. It doesn't simulate opening the IDE, loading the project, finding the right file, reading the surrounding code to remember context, setting up the test environment (setup time). It doesn't simulate the two Slack messages and one bathroom break that will interrupt the session (interruption/recovery time). It doesn't simulate saving, committing, updating the task tracker, and transitioning to the next task (teardown/transition time). You estimated 90 minutes of core work. The actual elapsed time was 2.5 hours.

The four-component decomposition forces these invisible phases into the estimate: Setup (finding materials, loading context, preparing the workspace — typically 5-20 minutes), Core work (the actual productive activity — what your intuitive estimate captures), Interruption/recovery (the statistical average of interruptions during a session — typically 15-30 minutes per 2-hour block), and Teardown/transition (saving, documenting, closing out, transitioning — typically 5-15 minutes). Omitting any component produces systematic underestimation because each is real elapsed time that doesn't appear in the intuitive estimate.

The 30-60% underestimation figure comes from the ratio between core work (what you estimate) and total elapsed time (what actually occurs). If core work is 60-70% of elapsed time, estimating only core work produces a 30-60% shortfall automatically.

When This Fires

• When creating any time estimate for a specific task
• When estimates consistently come in 30-60% low despite feeling reasonable at the time
• When planning a day and finding that "5 hours of tasks" somehow fills an 8-hour day
• Complements Three-point estimation: (optimistic + 4x realistic + pessimistic) / 6 — counteracts the optimism bias inherent in single-point estimates (three-point estimation) with the component-level decomposition

Common Failure Mode

Estimating only "work time" — the time spent actively producing output. This feels like the right number because it's the time that "counts." But elapsed time includes setup, interruptions, and teardown, all of which are real time that displaces other activities. Planning based on work time alone guarantees a schedule that doesn't fit reality.

The Protocol

(1) For each task, estimate four components separately: Setup: "How long to get started? Find files, load context, prepare workspace." Core work: "How long is the actual productive work?" Interruptions: "Over this duration, how many interruptions will realistically occur? At ~23 minutes recovery each (Never apply the two-minute rule during maker time — a 2-minute interruption costs 25+ minutes in context recovery during deep work), what's the total?" Teardown: "How long to close out, save, document, and transition?" (2) Sum all four components. This is your elapsed-time estimate. (3) Notice the gap between the core-work estimate (what your intuition gives you) and the total. This gap is the invisible overhead that causes chronic underestimation. (4) Over time, you'll develop intuition for the overhead ratios in your typical work contexts — but continue decomposing for unfamiliar tasks where overhead is harder to predict. (5) For back-to-back tasks, teardown from task A and setup for task B overlap — account for this to avoid double-counting.