Number one question: What don't I know yet? Known unknowns are what make an estimate a range. Unknown unknowns are what will make it completely useless. For

Number one question: What don't I know yet? Known unknowns are what make an estimate a range. Unknown unknowns are what will make it completely useless. For the known unknowns, make them knowns. Put together best and worst case scenarios. Weight your estimate towards the worst-case scenarios. Unknown unknowns, well... the trick is to turn as many of them as possible into known unknowns. Skim through the code you're extending, or sketch yourself a diagram of what you're building from scratch. Check your assumptions about APIs or available data. If it's a small project, have an idea as close as possible to exactly what lines you'll have to write/change to accomplish your task. If it's a very large project, write the tiniest possible proof of concept of the riskiest portion to validate your assumptions before giving an estimate. Make yourself a checklist of steps to complete your task. Break those down into at least three sub-steps for each step. Then break those steps down further until you're down to tasks that will take no more than two hours apiece to complete. Don't forget to include time for writing automated tests; for manual testing; and for fixing things that don't work the way you intended the first time around. If you're being asked for a turnaround time estimate rather than a person-hours estimate, don't forget to include time spent waiting for answers or verification from other stakeholders. If you're integrating with a third-party service, include time for back-and-forths with tech support, and for implementing workarounds because their platform doesn't actually do what it says it does the way it says it does, and (if they're a new vendor) for contract negotiations to drag on. Then multiply your estimate by two.