Every estimate I have ever given has been a lie. Some of them have been kinder lies than others. The point of estimating well is not to stop lying. It is to lie in ways that don’t blow up trust when reality arrives.
I learned this the hard way on a project I now think of as the “two-week ETL.” A stakeholder asked me how long it would take to build a new ingestion pipeline from a third-party API into our Postgres warehouse, with dbt models on top. I looked at the API docs for ten minutes, mentally walked through the work, and said “two weeks, maybe two and a half.” I genuinely believed that.
It took six. Not because the work itself was hard. The actual code, in retrospect, was about eight working days. The other four weeks were swallowed by an access-request lead time I hadn’t factored in (the security team needed to approve the API key, which took eleven business days), a vendor-side rate limit I’d missed, a schema change in the source data the day I started writing the dbt models, and a quietly stubborn bug in our timezone handling that ate three afternoons. None of those were unforeseeable. I just didn’t think about them when I gave my number, because giving my number took ten minutes and I wanted to get back to the work.
That project didn’t fail. We shipped it. But I had to send four “I need another week” updates, each one a little more sheepish than the last, and the trust I’d built with that stakeholder took a year to rebuild. The whole thing would have been smoother if I’d said “six to eight weeks” up front. The work would have been the same. The story would have been completely different.
Estimates are a social contract, not a measurement
The first thing to internalise is that an estimate is not a prediction. It is a promise about your future behaviour. When you say “two weeks”, what the person hears is “in two weeks, we’ll have this thing.” They will plan around that. They will tell their boss. They will book a demo. They will commit to a downstream team that something will be ready by then.
This is why “I think it’ll take a day” is so dangerous. The engineer who says it is making a private guess about coding time. The PM who hears it is making a public commitment about delivery. Those are different things. The gap between them is where careers go to get a little bit shorter.
So the question isn’t “how long will the work take?” It’s “what number can I give that, when reality lands, won’t have set me up to look bad and won’t have starved the project of urgency either?”
That’s a different question, and it has a better answer.
The three numbers approach
The single most useful thing I do when estimating is give three numbers, not one. Best case, expected, worst case. I picked this up from a project manager early in my career and I’ve never stopped using it.
The best case is the version where everything goes right. The data is exactly the shape you expect. The access requests come back same-day. There are no surprise edge cases. You don’t get pulled into any incidents. This number tells the stakeholder the floor.
The expected number is what you actually believe will happen, given your past experience with similar work, on this codebase, with this team. It’s the median outcome.
The worst case is the version where two or three things go wrong, but not catastrophically. Not “the company collapses.” More like “the API turns out to have undocumented pagination, and the dbt model needs a backfill, and the QA cycle takes a week.” This number tells the stakeholder the ceiling, in normal-bad conditions.
For my hypothetical two-week ETL, an honest three-number estimate would have been “best case 2 weeks, expected 4 weeks, worst case 8 weeks.” The expected number is double the original. That feels uncomfortably long when you say it. It also turns out to be roughly right.
Stakeholders almost universally appreciate the three-number version. It tells them you’ve thought about the work. It gives them the information they need to plan. And it gives both of you a shared vocabulary for the inevitable check-in: “we’ve burned the best case, we’re tracking towards expected” is a much healthier conversation than “we’re a week late.”
Why “I think it’ll take a day” usually means a week
There’s a specific failure mode worth naming. When an engineer says “I think it’ll take a day”, what they almost always mean is “the core technical work is one day’s worth of focused coding.” What they almost always forget is everything around the core technical work.
Reading the existing code to make sure you don’t break it. Writing tests. Getting a code review (which can take a day or three depending on team norms). Fixing the things the reviewer caught. Deploying it. Verifying it actually works in production. Updating the documentation. Telling the stakeholder it’s done. Handling the inevitable “wait, I meant something slightly different” follow-up. Each of those is small. Together, they triple or quadruple the estimate.
The specific tools matter. If your team has a five-minute deploy and a tight CI loop, the overhead is low. If you have to chase three reviewers across timezones, get sign-off in Jira, run a manual smoke test in a UAT environment, and update a runbook in Notion, the overhead is enormous. Same code change, very different timeline.
The fix is to consciously include the overhead in your number. I now mentally add up the focused-coding days, then ask “how long does it take a typical PR to get from open to deployed on this team?” and add that. The answer is almost never zero.
Padding 50% sounds like cheating, but it isn’t
A common piece of advice is “add 50% to your estimate.” This is good advice. It’s also widely ignored, because it feels dishonest. You don’t want to be the engineer who pads. You want to be the engineer who’s accurate.
Here’s the thing: the engineer who adds 50% is more accurate, on average, than the one who doesn’t. Studies on software estimation, and my own experience over more years than I’d like to admit, both point the same way. The unpadded estimate is the one that’s actually wrong.
The reason is that the things that make a project run long are usually invisible at the moment you’re estimating. The schema change. The flaky integration test that fails once a week. The colleague who turns out to be the only person with admin access to the staging environment, on holiday for ten days. The 50% pad isn’t a fudge factor. It’s an acknowledgement of the variance you can’t yet see.
What 50% padding actually does to a project is buy you slack. You hit your dates more often. You have time to handle the inevitable surprise. You don’t have to sacrifice quality at the end to ship on time. Your stakeholders learn that when you say a date, you mean it, which is a reputation that compounds across years.
The cost of being chronically late is much higher than the cost of being padded. Late is “I can no longer trust this engineer with anything important.” Padded is “this engineer hits their dates, sometimes a few days early.” Pick the second one.
Communicating uncertainty without losing trust
There’s a sentence I now reach for whenever a stakeholder asks for a date and I genuinely don’t know yet. “I don’t know yet. Give me two days to investigate, and I’ll come back with a real estimate.”
That sentence is gold. It refuses to give a fake number, which protects you. It commits to a small, defined investigation, which gives the stakeholder forward motion. And the two-day investigation is almost always enough to convert a ten-second guess into something actually defensible.
Most engineers I’ve worked with are afraid to say this, because they think it makes them look uncertain. It does the opposite. The engineers I trust most are the ones who say “I don’t know” out loud and then reliably come back with an answer. The ones I trust least are the ones who confidently quote a number based on nothing and then quietly miss it.
A related sentence: “this estimate is based on the work as I understand it. If [specific assumption] turns out to be wrong, I’ll need to re-estimate.” This protects the date and the relationship. It also signals that you’ve thought about what could go wrong, which is exactly what a stakeholder wants to hear.
Planning poker, t-shirt sizes, and when each is right
Two estimation rituals are worth knowing.
Planning poker is the thing where the team independently picks a number from a Fibonacci-ish scale (1, 2, 3, 5, 8, 13) for each ticket, then everyone reveals at once and discusses. It’s good for medium-sized work where the team has a shared sense of what a “5” feels like. It works because the disagreement surfaces hidden assumptions: when one person votes 3 and another votes 13, the conversation that follows is the actual estimate.
T-shirt sizes (S, M, L, XL) are good earlier in the lifecycle, when you’re roadmapping or grouping. They resist the false precision of putting “6 days” on something that hasn’t even been speced. “This project is a Large” is a much honester answer than “this project is 23 days” when you’ve spent half an hour thinking about it.
Both rituals only work if the team treats them as a conversation, not a ceremony. The number on the card is less valuable than the discussion the number triggers.
In the end, the goal isn’t to predict the future. The future will surprise you. The goal is to give numbers that, when the work is done, leave your stakeholders feeling like you knew what you were talking about, and feeling like the partnership was worth it. Three numbers, padded honestly, with the assumptions named out loud, and a willingness to say “give me two days” when you genuinely don’t know yet. That’s the whole craft. Everything else is decoration.