. My personal bias is that I really dislike under-estimating, and I typically over estimate how long tasks will take (by design) – but usually it’s pretty close (i.e. not an order of magnitude off).
1. Usually, the smallest unit is a week. When people say something will take a day, it’s usually wishful thinking – they forget about meetings, other commitments, etc.
2. Think about what “done” means for individual tasks when estimating. Often more junior engineers will give estimates where “done” means the code is submitted to source control – but really think about the work that it’ll take to get that code into production. Testing, configuration, documentation, monitoring/metrics/alerts, etc. I think a lot of under-estimating comes from this, where the estimates are just for writing the code, and all of the other stuff comes either as a scramble at the end, or a ton of time to actually launch as tons of bugs and missed features are discovered late in the game.
3. Think in latency and throughput. Estimates typically have both baked in – if something takes a week of “at-keyboard’ time, it might take a month to get done because of other commitments. Both estimates are important.
4. Think in probability distributions rather than absolutes. I usually set my threshold around 90% confidence – i.e. my estimates are based on where I am 90% confident I can have something done. When you think about how long something takes, if the stars align, a 10 day task might take 5 days, but if things go wrong, that 10 day task could take several months or more. Things can only go a little bit better than expected, or a lot worse than expected. But when people make estimates, I think they are often biased toward the “stars align” case, and forget about this fat tail.
5. With team estimates, add a friction value to longer term estimates to account for vacations, sick days, distractions, etc. Usually around 30% seems to work. So that one month task (20 days) I plan for it taking 20 * 1.3 = 26 days.
6. Work backwards from the end goal. This forces you to factor in things like testing and productionalization. This also helps with coordination too, as you can figure out when to parallelize tasks to get to the end goal.
7. Write estimates down, and go back and reflect. When something that you thought would take a week took a month, sit down and really think about why. This will help you recognize and refine your biases.