I use a mechanism I call "auto-padding". It works like this:

1. Break tasks into the smallest reasonable chunk you can -- if you can't measure the effort required in under a few hours (I use 6), it's not broken up enough.
2. Estimate the number of hours for each task.
3. Add up all the hours.
4. Now, define "a day" as 6 hours: divide your total hours by 6 to get the number of expected days:
   • Always round up
   • For projects longer than a few weeks, define a week as 4.5 days: divide your day count by 4.5 to get the number of weeks
   • When you have your weeks or days number, but you must supply an estimate in hours, use the business standard values and multiply back out: if you have a weeks number, take $weeks*40 (std 40-hr week); if a days number, take $days*8 (std 8-hr day).

Breaking your project into smaller tasks helps make your estimates more realistic.

Defining days as 6 hours and weeks as 4.5 days (of six hours each, note) gives you an automatic fudge factor that takes into consideration much of the unforseen events, meetings, vactions, sick days, and so on.

As an example, say I have the following task estimates:

Task	Hours
Implement foo	5
Implement bar	6
Implement foobar	3
Implement barfoo	6

I start with 20 total hours. I divide this by 6 to come up with 3.33 days -- I never give estimates in partial days, so I round this up to 4.

I've found estimating in this way to be reasonably accurate, as it accounts for "productive hours" rather than "work day hours". As a result, I often get finished a little early: in the above example, there's a good chance I'd finish a day early.

This gives me an opportunity to do more testing, clean up one or two things I thought were ugly but "good enough", etc. It also means I work a 40-hour week (usually), can take a leisurely lunch and regular typing breaks, and am able to spend some time reading PerlMonks -- but I still turn my work in on time.