‘How long is it going to take?’ Asks the client or the manager. It’s a tough question to answer, especially when you’re still processing all the requirements for the task. A time estimate should be well.. an estimate. It is easy for that estimate to become the deadline. An estimate requires you to make a lot of assumptions. On the surface, a task may appear easy, but can quickly become complex.

There is no right software estimation technique. But let me break down what I do when I give an estimate to someone. It as worked for me on large scale projects and even for individual tasks.

1. As you break the task in sub-tasks to build a road map. 
2. Assign a worst case and a best case for each one as if you were personally going to do them (ex 4 hours – 10 hours). 
3. Add all the worst cases and take the average. Do the same for the best cases. 
4. Add an additional 20-30% to each average
5. Present your estimate as a range from worst to best. 

That additional padding really depends on the skill level of your team and also takes into account you over estimating your skill level. There will also be meetings for those special corner cases that come up during development or were missed during the design meeting. 

Time estimating is a skill. No matter your current position, you will eventually have to estimate a task. First you start for your work, then delegate for a team, and later for whole projects with various teams.

Happy coding!