To estimate work in hours honestly, estimate the focused time the task needs, then multiply by a ratio you measured on your own past work rather than one you hope is true. Most people skip the second step, and that is why most estimates come in short: the number you give is a description of the plan going well, and the plan is the part of the job that never fails to go well on paper.
What is an hour estimate actually an estimate of?
Three different quantities get called “hours”, and mixing them up is the first source of error.
- Elapsed time: the clock from start to finish, lunch and interruptions included.
- Focused time: the part of that clock you were actually working on the task.
- Billable time: whatever your contract or client agreed to count, which may exclude setup, meetings or revisions.
An eight-hour day is eight hours elapsed. It is almost never eight hours focused, and when you say “this will take two days” you are quietly converting between the two. Decide which one you are estimating, say so, and keep it the same from one task to the next.
Why do estimates come in short?
The pattern has a name. Daniel Kahneman and Amos Tversky called it the planning fallacy in 1979, and later work by Roger Buehler and colleagues found that people underestimate even when they know their earlier projects overran. Knowing about the bias does not remove it.
The mechanism is simple. When you picture a task, you picture the steps in order with nothing going wrong. The missing file, the question that needs an answer from someone else, the second round of changes and the hour spent getting back into the problem are not in the picture, so they are not in the number. Each is small and unlikely on its own. Together, on a real task, some of them nearly always happen.
Should you pad every task or add one buffer at the end?
It depends on what is causing the error, and the two cases need different fixes.
A padding on each task tends to get spent. If you estimate four hours and add one for safety, the work expands to fill five, and the safety is gone before the task that actually needed it. People also hide the padding, which means whoever reads your estimate cannot tell which numbers are firm.
A single buffer at the end of the whole project is cheaper, for a statistical reason: when overruns are independent, some tasks run long and others run short, so the total needs less spare time than the sum of every task's own padding. That argument fails when the error is shared. If you underestimate everything by the same habit of mind, nothing cancels, and a pooled buffer sized for random noise is too small.
The way out is to measure which case you are in. That takes one week of records.
How do you find your own multiplier?
Write the estimate down before you start each task, log the real time afterwards, and divide. The honest version of this is dull, which is why almost nobody does it. An example, with invented numbers, for five tasks in one week:
| Task | Estimated (h) | Actual (h) | Actual ÷ estimated |
|---|---|---|---|
| A | 2.00 | 3.50 | 1.75 |
| B | 1.00 | 1.25 | 1.25 |
| C | 4.00 | 7.00 | 1.75 |
| D | 3.00 | 3.00 | 1.00 |
| E | 1.50 | 2.50 | 1.67 |
| Total | 11.50 | 17.25 | 1.50 |
Divide the total actual by the total estimated, not the average of the per-task ratios, so the big tasks count for more. Here the multiplier is 1.5: the next estimate of eight hours becomes twelve. Look at the spread too. One task landed exactly, four ran over, and none ran under. That is a shared bias, not noise, so a pooled buffer would not have saved this week and a multiplier would have.
To log the actual time, give each task its own row in the hours calculator, with the label, the start and the end, and read the total as decimal hours. It accepts times the way you write them and rounds each entry if you ask it to. It does not run a stopwatch for you and it does not remember: close the tab and the sheet is gone, so copy the totals out before you do.
How do you turn focused hours into a delivery date?
Do the conversion once, with a measured figure. Count how many focused hours you really get in a working week, which is lower than the hours you are present, and divide the multiplied estimate by it. A focus timer keeps a count of completed sessions and focused time while the page stays open, which makes the denominator something you read rather than guess. It, too, stores nothing after a reload.
Then quote a range, not a point. If your multiplier is 1.5 but ran from 1.0 to 1.75 across tasks, the honest answer to “how long?” is “between this and that”, with the low end being the case where nothing goes wrong.
What will a multiplier not fix?
- Work you have never done. A ratio measured on familiar tasks says little about a new kind of task, where the uncertainty is in what has to be done at all.
- Small samples. Five tasks is a starting point. One bad task can move the ratio a lot, so keep logging and expect the figure to shift.
- Different kinds of work. Writing, debugging and meetings overrun by different amounts. One multiplier for all of them blurs the picture, so split them once you have enough records.
- Changing scope. If the task grows while you work, you are not estimating badly, you are doing a different job. Re-estimate it and say so.
No one has a universal figure for how far estimates run over, and anyone quoting one is selling it. Your own log is the only number that applies to you.
Start with the adding. The hours calculator turns a week of start and end times into total and decimal hours in the page, with nothing uploaded, so a week of real figures takes minutes rather than an evening. The arithmetic behind it, including why 7:45 is not 7.45, is in how to add up hours worked.
If your focused hours are the part that surprises you, what the evidence says about timed work blocks covers what a timer can and cannot do for them.
Frequently asked questions
Why do I always underestimate how long a task will take?
Because you estimate the plan, not the work. Picturing a task means picturing its steps in order with nothing going wrong, so interruptions, waiting on other people, rework and the time spent getting back into the problem are missing from the number. Psychologists call this the planning fallacy, and it persists even when you know your earlier projects ran over.
How do I calculate how long a project will really take?
Record the estimate and the actual time for a set of finished tasks, divide the total actual by the total estimated, and multiply your next estimate by that ratio. For example, 17.25 actual hours against 11.5 estimated gives a multiplier of 1.5. Treat it as a range, because the ratio varies from task to task.
Is it better to add a buffer to each task or to the whole project?
A buffer on each task tends to get used up by that task, and it hides which numbers are firm. A single buffer at the end can be smaller when overruns are independent and cancel out. If you underestimate everything by the same habit, they do not cancel, and a measured multiplier works better than either buffer.
What is the difference between elapsed hours and billable hours?
Elapsed hours are the clock from start to finish, breaks and interruptions included. Billable hours are only what your contract or client agrees to count, which may exclude setup, meetings or unpaid revisions. Focused hours, the time you were actually working on the task, are a third quantity and usually the smallest of the three.
How many tasks do I need to log before the multiplier means anything?
There is no agreed minimum, and nobody has published a figure that applies to everyone. Five tasks gives you a first guess, but one unusual task can move it a long way. Keep logging, compare kinds of work separately once you have enough, and expect the number to settle slowly.
Last updated October 1, 2026
