Estimate Honestly
Give a range, name the assumptions holding it up, and say what it would take to make it narrower.
When to reach for it
When someone asks how long something will take and you can feel yourself about to answer with one confident number.
What changes
- You answer with two ends you would each defend, rather than a single number that is really a hope with a deadline attached.
- The assumptions are listed with their consequences, so “this doubles if the endpoint is public” is visible before it happens rather than after.
- Unknown work is timeboxed for investigation instead of estimated, which separates “I have done this” from “I have never seen this”.
- Review, deployment, documentation and the fix after the first real user are inside the number instead of arriving as a surprise afterwards.
- When an assumption breaks you revise on the day it breaks, so the change reads as information rather than as a broken promise.
Pairs with
- Disagree With the BriefPush back on a requirement that will not survive contact with reality — with a specific failure case and a way forward.
- Ask One QuestionWhen you are blocked, work out the single question that unblocks the most — and ask that one, well.
- Explain the WhyRecords the reasoning a diff cannot show — what you rejected, and what would make this the wrong choice later.
Estimate Honestly
An estimate is a claim about uncertainty. Report the uncertainty, not just the middle of it.
1. Separate what you have done before from what you have not
Two lists. The first can be estimated from experience. The second cannot be estimated at all yet — and that is where estimates go wrong, never in the parts you already understood.
2. Timebox the unknowns rather than guessing them
"Two hours to find out whether that export API supports pagination, then I can size the rest." Selling the information first is faster than selling a number you will have to withdraw.
3. Estimate the whole job, not the coding
Count what always happens and is always left out: setting up the environment, reading the surrounding code, tests, review and the round trip after it, deployment, the documentation nobody mentioned, and the fix after the first real user meets it.
4. Give a range with both ends honest
The fast end assumes nothing surprises you. The slow end assumes the two surprises you can already name both happen. Not a fantasy floor and a padded ceiling — two numbers you would defend separately.
5. Attach the assumptions
Three to five sentences that could each turn out false, with their effect:
- "Assumes staging has the same data shape. If not, add a day."
- "Assumes I can change the endpoint. If it is public, this doubles."
This is the part that lets an estimate be revised without it looking like a promise being broken.
6. Say what would narrow it
"Half a day on the import would turn three-to-eight days into four-to-five." Then let the person asking decide whether that precision is worth the half day. It is their trade, not yours.
7. Revise the moment an assumption breaks
On the day it breaks, not at the deadline. An estimate revised early is information; the same revision late is a surprise, and surprises are what people actually remember.
Rules
- Do not give a single number. A single number is a promise you did not intend to make and will be held to anyway.
- Do not estimate work whose shape you have not seen. Buy the information first.
- Do not let a deadline you were handed become your estimate. Say what fits inside it, and what does not.
- Do not pad in silence. A hidden buffer gets spent invisibly and you are still late; a stated range can be negotiated.
- Do not estimate for someone else's hands without saying whose hands you assumed.