Ask an engineer how long a feature will take and watch what happens. There is a pause, a glance at the ceiling, and then a number that sounds confident enough to end the conversation. "Two weeks." That number is not a forecast. It is a polite way of saying please stop standing at my desk. I have given that answer myself, and I have accepted it from others, and almost every time the real story was hiding underneath it.
The mistake most teams make with estimation is treating the number as the deliverable. We ask for a figure, we write it on a plan, and then we are surprised when reality drifts. The figure was never the point. A good estimate is the residue of a conversation about scope, risk, and what done actually means. Skip the conversation and the number is a guess wearing a suit. Have the conversation and the number becomes something you can defend, revise, and trust.
The number is the last thing you should ask for
When someone hands me a single number with no preamble, my first question is never "are you sure?" It is "what are you assuming?" Every estimate sits on a stack of assumptions, and the person giving it usually has not made those assumptions visible, sometimes not even to themselves. They are assuming the design is final. They are assuming the third-party API behaves. They are assuming nobody asks for a dark-mode variant halfway through. The number compresses all of that into one digit and throws the context away.
So I have trained myself, and our product teams, to treat the request for an estimate as the opening of a discussion rather than the close of one. Before anyone commits to a timeline, we want three things on the table: what is in scope and what is explicitly not, where the real risk lives, and what the word "done" covers. Most of the value of estimation is generated right there, before a single hour is forecast. You frequently discover that the thing you were about to spend two weeks on can be cut in half because half of it was never required, or that the small task is actually load-bearing for something nobody mentioned.
Scope is where estimates go to die
Almost every blown estimate I have investigated traces back to scope, not to slow work. The team did not type too slowly. They built something larger than the thing that was estimated, because the thing that was estimated was never pinned down. "Add export" sounds like one task. In practice it is a question: export to what format, with which fields, respecting which permissions, and what happens when the file is too large to generate in a single request? Each of those forks the work, and each fork was invisible in the original ask.
This is why good estimation and good scope definition are the same activity. You cannot honestly size something you have not bounded. When I push a team on an estimate, I am usually not pushing on speed at all. I am pushing on the edges: show me where this stops. The act of drawing that boundary is what turns a guess into a plan. And once the boundary exists, you can negotiate it. You can say the first version exports CSV only and the rest is a follow-up. That negotiation is impossible if all you have is a number.
Example: A team estimates a "simple" notifications feature at one week. In the scoping conversation they list the cases: in-app, email, digest versus immediate, per-user preferences, and unsubscribe handling. The honest estimate for all of that is closer to a month. They ship in-app only in four days, learn what people actually want, and build the rest with evidence instead of speculation. The one-week number would have been wrong. The conversation made it right.
Risk deserves a name, not a buffer
The usual response to uncertainty is padding. You think it will take five days, so you say eight, because experience has taught you that things go sideways. Padding is not wrong, exactly, but it is lazy, and it hides information that the rest of the team needs. A padded number tells me you are nervous. It does not tell me what you are nervous about, which means I cannot help you reduce the risk.
I would rather a team say: the core work is three days, but there is one part we have never done before, the payment reconciliation, and that could be one day or it could be five depending on how the provider's edge cases behave. Now we have something to act on. We can spike the risky part first, before committing to the whole timeline. We can decide it is too uncertain and descope it. We can put a senior person on that piece specifically. Named risk is actionable. A buffer is just anxiety baked into the schedule.
The best teams I have worked with estimate ranges for the uncertain parts and commitments for the known parts, and they tell you which is which. That honesty is worth more than precision. A range that is correct beats a point estimate that is confidently wrong, every time.
What "done" means is a negotiation, not a given
The third thing that wrecks estimates is a quiet disagreement about the definition of done. The engineer estimated time to working code. The product manager assumed it included tested, documented, and behind a feature flag. The designer assumed a polish pass. Nobody lied. They just held different pictures of the finish line, and the estimate only covered one of them. The gap surfaces at the worst possible moment, which is when everyone thought the thing was shipping.
So we make the definition of done explicit in the same conversation. Does this need tests? Does it need a migration path for existing data? Does it need to be accessible, localized, instrumented so we can measure whether it worked? Each yes adds time, and each one is a legitimate decision rather than an assumption. When done is agreed up front, the estimate describes the same object everyone is imagining. When it is not, the estimate describes a fantasy that only one person can see.
Make the conversation cheap to have
If estimation is a conversation, then the practical work of project management is making that conversation cheap, frequent, and recorded. Not a quarterly planning summit. A quick, structured exchange that happens whenever real work is about to start, and leaves a trail you can look back on when reality diverges from the plan. The teams that estimate well are not blessed with better intuition. They have a habit of writing scope, risk, and done somewhere durable, and revisiting it.
This is mundane, and the tooling matters less than the discipline, but the tooling should not get in the way. Inside Atlas we keep the scoping notes, the risks, and the acceptance criteria attached to the task itself, so the conversation that produced the estimate lives next to the work instead of evaporating in a meeting. When the number turns out to be wrong, and some of them always will, you can see exactly which assumption broke. That is how estimation gets better over time: not by guessing harder, but by closing the loop between what you said and what happened.
So the next time someone asks you how long something will take, resist the urge to produce a number that makes them go away. Ask what done means. Ask where the risk is. Draw the edges of the scope out loud. The number will come, and it will be better, but the number was never the goal. The shared understanding is. That understanding is what lets a team plan together instead of negotiating blame later. The figure is just where the conversation happens to land.