This is what a client asked me recently. I would state, for example, that a task would take 160 hours instead of 154 hours.
Why do you round your estimates upwards?
If the estimates are too finely tuned (i.e. 157.5hrs) it would create a false sense of accuracy. It’s impossible to have absolute conviction that a task will take 157 hours either. 160 might even give a false sense of accuracy, but a lesser one at that. 200 hours would have been better (i.e. more human).
Then why round up instead of down?
- Software estimates are usually under-estimated, not over estimated. The industry definitely does not have an over-estimation problem.
- However, the penalty for under-estimation is greater than the penalty for over-estimation. These penalties come in various shapes and sizes, but one flavour – disappointment. They include:
- Drop in code quality due to rushing
- Budget over-runs
- Bugs introduced due to rushing
- Drop in UX quality due to rushing
As much as The Quantified Self movement has challenged individuals to get more accurate at measuring their efficiency down to the mega-watt produced in lifting a pencil, years of experience in project management has taught me that prudence is precious. This is why I’ll round up, and (usually) over-deliver.