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?

I explained:

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.