TL;DR
In the previous post, we learned how to do project estimates. In this post, you will find out tips for making project estimates easier. The post is based on a remarkable book written by Johanna Rothman, Manage It!
Estimates Is Always A Guess
There is no formula where you can put a list of parameters (programming language, architecture, feature name), and the result would be the exact estimate of work in man-hours. Every estimate is a guess. The bigger the estimate, the bigger is estimate error. The client or product owner must be aware that this is a guess, so always estimate with three date ranges.
Most People Are Optimistic
Which means that estimate would be undershot. The School system trains us to be an optimist in estimation. Our projects were semester-long and heavily underconstrained, and there was enough time to finish it on deadline.
Task Duration
Even a one-hour task estimation will take longer. This is how software development works.
Smaller Chunks
But estimation error in one-hour work would be much less than one-week task chunk.
Estimation Metric
Usually metric is person-days of person-hours. With person-hours, you will avoid client assumptions about how long is your working day.
Reestimates
At the start, my biggest mistake with estimation was that I did not make notes of how much time I needed to do the actual task. Iterating on estimates would give you a chance to compare your estimation with real work. So your next estimation could be more precise. Even if your project is on time, do the reestimates because you could learn why the estimate was so accurate.
Deadline
With a hard deadline, there is no point in estimates. You know when you need to be done. What can do is to do feature-oriented development in the Agile lifecycle. Features should be prioritized and connected (which features are preconditions). With timeboxing your work, you will have information about what could be delivered at the project deadline.
