How I estimate a task I've never done before
Most bad estimates aren't bad math. They're a confident guess about the part of the task nobody has looked at yet.
Here's how I estimate work I've never done before.
1. Split it until every piece is something I've done before.
Most of a "new" task isn't new: a form, an endpoint, a migration, a test. The pieces I can't name are the real estimate — everything else is arithmetic.
2. Find the unknown first, and try it.
Before committing to a number, I spend a few hours on the riskiest part: the unfamiliar API, the library nobody on the team has used, the data I haven't seen. Half a day of trying beats a week of guessing.
3. Give a range, not a point.
"2 to 4 days" carries information that "3 days" hides: how unsure I am, and why. The width of the range is the honest part.
4. Count the work around the work.
Code review, tests, deploy, the questions to the product side, the edge case that shows up on day two. It's rarely in the estimate. It's always in the calendar.
5. Re-estimate out loud.
An estimate is a forecast, not a promise. The moment I learn something that changes it, the people depending on it hear it from me — not on the deadline.
The honest nuance: the goal isn't accuracy. It's no surprises. A task that's late but that everyone saw coming a week ago is fine. A task that surprises everyone on the due date is the real failure.
An estimate isn't a number. It's a list of what you don't know yet.
How do you estimate work you've never done before?