Good stuff for discrete tasks. We have a similar practice, but it's a step removed from the developers; it's our time-tracking and project management software. It tracks estimates and actuals. The problem is, I don't think developers ever go back and look at the differences or review how they did with their estimates. Your suggestions above are directly aimed at being very self-aware to improve the estimates, which is a good goal. I think we've fallen into a slightly different mode where our project managers look at the past data and apply their own factor to each developer's estimates.
in reply to Improving Your Ability to Estimate
In other words, they learn that developer X is routinely short by half, so they double all of her estimates. In some cases we have developers who are over-cautious, so they take 75% of their estimates. Don't know if this is better or worse. I guess the developers don't have to change, but they certainly don't become any better at estimating.
My estimation problems are a little deeper with my position. I act as a technical manager on projects which means I run into two difficult estimating tasks:
- In some cases, I need to estimate time for a task without knowing who will code it. It's well documented that coders work at very different levels of productivity. I have more experience, so my estimates would be too low. So I estimate, then double it. When the project starts, we sometimes make another pass once actual developers have been assigned.
- Most of my own tasks are very ill defined, so it's difficult for me to estimate for myself. For example, one task might be 'Research bug tracking products,' or even 'Figure out how we should validate our forms.' Lately there has been some great discussion on perlmonks on validation, so I might find that and finish quickly. In other cases, it takes me a while to track down best practices on something. I still have a very hard time estimating these ill-defined tasks.