Someone asks “how long?” You say two days because two days sounds responsible. The work has an unknown vendor, a migration, and a designer who is on leave. Four days later you are still on the vendor. Trust drops. Next time you pad until the number is meaningless. That is also a lie, just a safer one.
Estimation is not prophecy. It is a way to expose risk and to choose a slice that can ship. This is how to estimate without pretending you have a crystal ball, and without sandbagging until planning is a joke.
What an estimate is for
The team needs to sequence work, not to punish you. A date is a promise to other people: marketing, support, a customer. If you cannot promise a date, promise a discovery: “I need a day to know.” That is an estimate of learning, which is honest.
Story points as velocity religion will not save you if the stories are novels. Time estimates will not save you if you ignore the unknown. The useful output is: known work, unknown work, and a first slice that fits in a few days.
Split the unknown out
Write two lists. Done-known: the CRUD, the copy, the tests you always write. Done-unknown: the vendor’s sandbox, the data quality, the browser that only the customer uses, the permission model nobody documented.
Estimate the known in hours or days if you must. Cap the unknown with a spike: a time-boxed investigation with a written answer. “Spike: 4 hours. Output: can we use their API to refund, yes/no, plus a sample payload.” After the spike, estimate the rest. Estimating the unknown before the spike is fiction.
If they want a number before the spike, give a range: “1 day if the API has refunds, 2 weeks if we have to fake them, spike tomorrow to know which.” Ranges are not weakness. Single numbers on unknown work are the lie.
The hidden work you always forget
Code review rounds. QA. Design polish. Copy from legal. Feature flags. Monitoring. Migration and backfill. Documentation. The second browser. Accessibility. The admin tool. The email. The rollback plan.
If you estimate “the happy path in my editor,” multiply. A personal factor of 1.5–2x for “done in production” is not padding for laziness. It is the rest of the job. Say it: “two days to a working branch, four to production-ready.” Then people can choose.
Meetings and support rotations steal the calendar. A 2-day task in a week of on-call is not two days. Say you are on-call. The estimate is calendar time, not laptop time, if they are asking when it ships.
Cone of uncertainty, in human words
At the start you can be off by a lot. After a spike, less. After a prototype, less. Do not give a customer-facing date at the start of a vague epic. Give an internal date for the next checkpoint.
If a PM needs a quarter plan, plan in outcomes and checkpoints, not in a Gantt of lies. “We will know after the spike on Thursday whether this is a month.” That sentence is how adults plan.
Hours, days, points
If your team uses points, use them as relative size, not as hours in a hat. If they convert points to dates with a spreadsheet, you are back to lying with extra math. Push back: velocity is a trailing average, not a contract.
If you use hours, never estimate under two hours for something that needs a PR. The overhead is real. Never estimate a two-week block as one task. Split.
When you are wrong
Say so early. “I was wrong, the vendor cannot do X, here is the new range.” Early bad news is a gift. Late bad news is a surprise launch miss.
Do not silently work weekends to hit a number you invented. That trains the org to believe the number. Then they will stack more.
If the scope grew, name the new scope. “You added PDF export; that was not in the two days.” Scope change is not a personal failure.
How to answer in the meeting
“I don’t know yet. I can tell you after a 3-hour spike, or I can give 2–10 days with the risk listed.” Then list the risks. People can decide to buy the spike.
If you do know: “Three days to PR, I want a day of review and QA, ship Friday if nothing in legal.” Conditions are part of the estimate.
Personal calibration
Track a few tasks: estimated vs actual. You will learn you always forget tests, or always forget CSS, or always crush backend and miss mobile. Calibration is how estimates get less wrong. Shame is not.
Dependencies and other people’s time
Your estimate assumed the API exists. It is not reviewed. Add “waiting on #1843” as a line, not as silent hope. If design is “final” but has never been in a phone frame, add a day. If legal must approve copy, they are on the critical path. Put their names in the estimate so the date is a team date.
Parallel work: two people on one file is not 2x speed. Call out merge contention. Sometimes the estimate should be “one person, four days” not “two people, two days.”
Saying no to false precision
“Will it be done by the 19th?” If the range is 12–22, say the 19th is possible if the spike is yes and legal is fast. Do not say yes to be liked. A late yes is more expensive than an early maybe.
Re-estimating after a surprise
You opened the file and the “two-day” task is a distributed lock you have never seen. Stop and re-estimate that day, not after you have already spent the two days. A 15-minute message: “this is a lock plus a migration, new range is a week, here is a first slice of two days.” That is professionalism.
If you are junior and afraid to re-estimate, do it anyway. The alternative is a silent miss. Seniors prefer the message.
Estimates in interviews vs on the job
Interview “how long to build Twitter” is a different game. On the job, you have the real repo. Use the repo. Open the module. Then speak. A number without opening the code is theater, unless the work is truly cookie-cutter and you have done it last month.
Buffer you can explain
A 20% buffer for integration work is not a lie if you say it is for review, QA, and the unknown you always hit in this codebase. A 300% buffer you cannot explain is sandbagging. The difference is whether you can name the extra work. Name it.
The demo date
If there is a customer demo, estimate to a rehearsal, not to “it works on my branch.” Demo-ready includes seed data, a script, and a rollback if the demo env dies. That is extra time. Put it in the number.
Artikals is a DEV-style place for this because engineering culture is still full of “just tell me when.” You can refuse the false precision and still be useful. Split known and unknown. Time-box the unknown. Include the production tax. Update when you learn. That is not lying. That is the job.
