A simple way to estimate tasks when every guess is wrong
Instead of guessing a single number, estimate a task's low end (if nothing goes wrong) and its likely end (accounting for one normal delay), then plan around the second number. This two-number method catches the specific error most people make: estimating from the smoothest possible version of the task instead of the version that actually happens.
The number you say out loud is usually the wrong one
Ask yourself how long it will actually take to reply to that one email sitting near the top of your inbox, and a number appears almost instantly: five minutes. That number is not exactly a lie, it is simply the time the task would take if nothing else were true about your day, your inbox, or the email itself. The actual number, once you factor in finding the thread, remembering what you meant to say, and getting distracted once while writing it, is closer to twenty. The gap between those two numbers is not laziness. It is the difference between the smooth version of a task and the real one.
Step one: name the low-end number
Start with your gut estimate, the number that comes to mind in the first two seconds. This is not wrong, it is just incomplete. Call it the low-end number, since it represents the task with no friction at all: no hold music, no missing form field, no getting pulled into a different tab. Write it down or say it to yourself clearly, because you are about to compare it to something.
Do not skip this first step by jumping straight ahead to a padded, rounded-up guess. The low-end number is useful on its own, since comparing it to the final estimate is what shows you how much friction a given category of task tends to carry.
Step two: name one thing that will probably slow it down
For most tasks, there is a predictable source of friction, and it is usually the same one every time that type of task comes up. A phone call to a business almost always includes hold time. A form almost always requires a piece of information you have to go look up. An errand almost always includes parking or a line. Name the specific friction for this task, not a vague "something might go wrong," and estimate how much time that one thing usually adds.
Step three: add them together and use that number
Low-end plus the named friction gives you the likely-end number, and this is the one that goes on your schedule, not the low-end guess. Say the task is calling to dispute a charge. Low-end: five minutes. Named friction: being on hold, usually ten to fifteen minutes based on past calls like this. Likely end: eighteen to twenty minutes. Scheduling eighteen minutes for that call, instead of five, means you are not still on the line when the next thing on your list was supposed to start.
Notice that this is not the same as padding every estimate by a fixed amount. The eighteen minutes came from a specific, named cause, hold time, not from a generic rule to add ten minutes to everything, which means the estimate stays accurate rather than just larger.
A worked example across a whole afternoon
Say your afternoon has three tasks: refilling a prescription (low-end 5, friction: pharmacy line, likely 15), replying to a work email (low-end 5, friction: rereading the thread, likely 15), and picking up dry cleaning (low-end 10, friction: parking, likely 20). Guessed at low-end, the afternoon looks like twenty minutes total. Estimated at likely-end, it is fifty minutes. That thirty minute gap is exactly the size of the surprise that usually derails the rest of the day when the low-end guess is what made it onto the schedule.
When the friction is something other than time
Some tasks run long not because of an external delay but because starting them is hard, which is a different problem than mistiming them. If a task keeps getting the same generous time estimate and still never happens, the issue is probably not the estimate. Finding the smallest next step of a stuck task addresses that version of the problem directly, and planning for the real day instead of a perfect one covers what happens when several of these estimates collide in the same afternoon.
Getting faster at this over time
The two-number method takes longer than a single guess for the first few weeks, since naming a specific friction requires a moment of thought a flat guess skips entirely. That extra moment shrinks quickly once you notice the same friction categories repeating: calls involve hold time, forms involve missing information, errands involve parking. After enough repetitions, naming the friction becomes close to automatic, and the whole two-step process takes barely longer than the single wrong guess it replaced.
Common questions
Why does the two number method work better than just trying to guess higher?
Guessing higher without a method tends to either overcorrect on quick tasks or undercorrect on tasks with real hidden steps. Naming the likely delay specifically, rather than adding a vague buffer, targets the actual source of the error instead of applying a flat tax to every estimate.
What counts as a normal delay I should plan for?
Anything that happens often enough to expect it: being on hold, a form asking for information you have to go find, traffic, a person you are meeting running a few minutes behind. A rare event, like a car breaking down, does not belong in a normal estimate.
Should I write down both numbers or just the final one?
Writing both helps over time, since comparing your low-end guess to what actually happened trains you to notice the gap. If you only have time to write one number, use the likely-end number, since that is the one your schedule should be built around.
This article shares practical organizing ideas. It is not medical advice. For diagnosis or treatment questions, talk with a qualified clinician.