Your estimates are not wrong, your unit is

The standard complaint about estimates is that they are wrong. They are, but not in the way the complaint implies. People are reasonable at judging whether a piece of work is small, medium or large. They are hopeless at converting that judgement into a number of hours for something they have not started.

The error is not in the judgement. It is in the unit.

Where the hours go wrong

Ask someone whether a task is bigger or smaller than the one they finished on Tuesday and they will usually be right. Ask the same person how many hours it will take and the answer degrades badly, for three reasons that have nothing to do with skill.

Hours are a forecast about the world, not about the work. An eight-hour task takes eight hours only if nothing interrupts it, nobody needs a review, and the thing you depend on behaves. Most estimates are secretly estimates of your calendar.

The unknowns are asymmetric. Work can surprise you in one direction far more easily than the other. Nothing turns out to take a quarter of the time; plenty turns out to take four times.

You are estimating the version in your head. Which is the clean one, without the migration, the edge case, and the thing the designer meant but did not draw.

None of that is fixed by trying harder. It is fixed by estimating something closer to you.

Estimate the next chunk only

An estimate for a whole feature is a forecast about work you have not seen yet, which is a different and much harder activity than estimating the thing in front of you. So do not make it. Estimate the next chunk, the part you can picture, and re-estimate when that chunk is done and you know more.

This feels like avoiding the question. It is actually answering a question you can answer, instead of guessing at one you cannot.

The practical form is a rule about horizon: never estimate beyond the point where you would have to guess. If you can picture the next half-day, estimate the next half-day. If a task is so vague that the honest estimate is "between a day and a week", that is not an estimate, it is a signal that the task needs splitting before anyone commits to anything.

Splitting is the actual skill. Most teams treat it as overhead and then spend a fortnight defending a number they invented in fifteen minutes.

Let the logged time argue back

An estimate with no feedback loop is a wish. The loop is simple: put an estimate on the task, log time against it, and look at the pair when the task closes.

In Timato an estimate is a duration, not a count of pomodoros, and it is optional. That is deliberate. A task with no estimate shows the time logged and nothing else, which is a complete and honest answer. A task with an estimate shows logged against estimate, and once it goes past, it says by how much rather than hiding it.

An estimate is not a promise. It is a hypothesis that the logged time gets to falsify.

After a month of pairs you stop needing the ritual: you know that your "half a day" is reliably a day and a half, and you adjust at the source. That correction is worth more than any estimation technique, and you can only get it from your own numbers.

The ratio, and what it is for

After twenty or so closed tasks you can read something useful: the ratio of logged time to estimated time, for you, on this kind of work.

Most people land somewhere between 1.4 and 2.2, and the number is remarkably stable within a kind of work. That is the point: a stable bias is not a flaw, it is a calibration constant. Stop trying to estimate better and start multiplying.

The ratio also moves with context in ways that are worth noticing. It is usually near 1 for work you have done many times, and worst on anything involving a system you do not own. If yours is above 3, the problem is almost never optimism; it is that the tasks are too big to picture, and the fix is upstream.

What not to do with this

Do not turn the pairs into a performance measure. The moment an overrun costs someone something, estimates inflate to cover the risk, the loop closes, and you are back to wishes with better padding.

This is not a hypothetical failure. It is the single most common way estimation practice dies: someone starts treating the estimate as a commitment, the first overrun gets a raised eyebrow, and within two sprints every number carries a silent safety margin. The estimates now look accurate and mean nothing, which is worse than where you started, because the padding is invisible and the feedback loop is gone.

Keep the pairs private to the person doing the work, or at most visible to a lead who has explicitly given up the right to be annoyed by them. The value is in the correction, and the correction only happens if being wrong is free.

The short version

• Estimate the next chunk you can picture, not the whole feature.
• If you cannot picture it, split it. The estimate was never the problem.
• Log time against the estimate and read the pair when the task closes.
• After twenty tasks, use your ratio instead of trying to be less optimistic.
• Never let the pair become a performance measure, or all of the above stops working.

None of this makes estimates accurate. It makes them useful, which is a lower bar and a much better deal.