Estimating Tasks: How Much Time is in Your Day?

I plan on about 6 hours of work in a regular day. That's project work, not answering the phone, email, making arrangements for workshops or consulting or speaking, or invoicing, or any of the other things I do. Nope, that's just project work.

The other half of that question is how many regular days do I have in a week? Either 3 or 4. I've had weeks with fewer "regular" days, where I could only accomplish 2 or 3 hours of work. This week, I've had 2 regular days (6 hours of work days) and 2 irregular days, where I accomplished maybe 3 hours of project work.

Since I make my own commitments, this usually works out. But not always. When it doesn't work--when I don't have enough project time in a week, I'll work on the weekend. I hate to do that because I don't have enough brain cells to work effectively the next week, making fewer regular days the following week.

If you know how much project time you have day-by-day, you have a much better chance of estimating your work on a project. So when you think about estimating your time for a given task, think about what you can accomplish in a regular day. And think about how many regular days you have in a week. If you only have one day a week where you can accomplish 6 hours of work, and the rest you can accomplish 4 hours, plan for the 4 hour every day. You won't have less to do over time--you'll have more.

Estimating What's Remaining to Finish

Pawel caught me being ambiguous. See his comment, "1. I've seen features/fixes which required 2 days to be developed and released."

Sorry, me too. But what I tried to say was this: A feature was estimated to be some duration of person-hours. Those person-hours have come and gone. The feature still requires another 10-12 person-hours, according to the developer. In that case, I don't trust the estimate of 10-12 person-hours left. In my experience, the reasons for the delay generally have not been addressed. If interruptions caused the delay, more interruptions could still happen. If the delay was caused by having to change the architecture, that could happen again (and I suspect it's likely). In my experience, until the feature is done, it's quite difficult to predict when it will be done, which is why I like to start a new iteration to make sure it gets done.

I tried to imagine what would convince me that an updated estimate was more accurate. In the past I've only had one thing that would convince me: I would have to see visible progress of more work complete (more pieces of the feature complete) to agree that the estimate of what's remaining to finish is correct. I'm trying to think of more things, and can't right now.