Estimating software development time is hard. There are so many variables, unknowns, “unknown unknowns”, and the specification always changes. Besides that, developers tend to be optimistic by nature.
Here’s a handy little way to come up with a quick, yet accurate estimate:
- Come up with your best, overall estimate that you feel is realistic using your favorite technique, or pure “gut feeling” if you are a very experienced developer and you know the problem domain well.
- Ok, you have your absolutely realistic number now, right?
- It’s not realistic. I guarantee you there are aspects you haven’t thought of. Double the number. This is your best case scenario estimate. This is how long it will take assuming everything goes well and there are no snags or major changes along the way.
- Now double it again. This is your most likely estimate. This is how long the project will probably take, when all is said and done.
- Now double it a final time. This is your worst case scenario. If things go really badly, or you run into several major issues, it could take as long as this.
So to sum up:
- E = Your best original time estimate
- 2(E) = Best case scenario time in reality
- 4(E) = Most likely time in reality
- 8(E) = Worst case scenario time in reality