Estimating tasks without lying

Why everyone underestimates

When estimating, people picture the happy path: sit down, write it, it works. Everything else the work consists of doesn't make it into that picture.

Missing: chasing an incomprehensible error, reading the surrounding code, redoing things after review, waiting for answers, meetings, urgent interruptions.

Hence a durable rule: the real duration is usually two or three times the first estimate. That isn't a character flaw but a property of estimating itself.

Estimating more honestly

Break it down until it's comprehensible. A task you can't estimate is too large. Split it into half-day pieces.

Splitting usually surfaces what you hadn't considered. That's the missing time.

Estimate the pieces and add them. A sum of small estimates lands closer to reality than one large one.

Add for the unknown. Not "just in case" but deliberately: if the task involves an unfamiliar technology or unfamiliar code you must understand, multiply.

Count in days, not hours. An eight-hour working day doesn't yield eight hours on a task. Realistically three to five.

About relative estimation

Many teams estimate not in hours but in relative sizes: this task is twice that one. They then observe how many such units the team completes per period.

The point is that people estimate absolute time badly and relative size noticeably better. "It's about like that task, only slightly harder" is an easier judgement to make.

A beginner should know the approach exists and not be alarmed when planning produces numbers that clearly aren't hours.

What to say when you don't know

Honestly: "I can't estimate until I've looked into it. Give me half a day to investigate and I'll give you a figure."

That's a normal professional answer. Far worse to name a number blindly and be three times out — because plans get built on your estimate.

A second option: give a range. "Two days if the data is in the shape I expect, up to a week if the storage needs reworking."

An estimate isn't a promise

The crucial thing to understand and to be able to explain.

An estimate is a forecast from currently known information. A promise is a commitment. They get confused constantly, hence the conflicts: the developer estimated three days, the manager heard "ready on Wednesday".

Say the difference out loud: "I estimate three days. If it turns out the data is shaped differently, that grows — I'll tell you as soon as it's clear."

When you realise you won't finish

Say so immediately. Not an hour before the deadline. The same day you know.

This is the most frequent and most expensive beginner's mistake: holding on until the last moment hoping it'll somehow work out. It almost never does, and by then the team has no room to manoeuvre.

"I won't make it, I need help or we need to cut scope", said in time, is received normally. Silence until the deadline isn't.

Learning it

Record your estimates and the actual time. After ten tasks you'll have a personal coefficient: you'll know by how much you specifically are out.

It's one of the clearest markers of experience. And you can practise on your own project: estimate every task before starting and compare afterwards.