Meryl's Notes Blog

Matt Berther points to a thought-provoking entry by Christopher Hawkins who knows how to produce an accurate estimate and shares what to avoid when doing the estimates for a project. I believe historical data is one of the best ways to become an accurate estimator. Mark and Christopher offer good points.

1. The first rule is to not let non-techies do the estimating. Disagree there. Add the word alone and I am om board with ya. Too many projects have failed because the test team wasn’t involved from the get go or so and so team was not included in this portion. Requirements and estimation should involve all teams. Like Matt says, it’s about getting buy-in not determining how long it takes to develop x functionality.

2. Post-mortems are rarely done right or to the full effect. I remember being part of a post-mortem and then following up with the project manager asking if any of the items had been addressed in future projects. Sadly, I was not surprised when she said, “No.”

3. Bugs are still killing us. But of course, process changes are killing us more. One year, we were doing releases four times a year. The next, it was monthly. Then, back to four times a year. With the constant changes to the release process, it’s no wonder we can’t keep up with anything.

4. We use requirements as a root cause in our bug tracking database. It shows up a few times, in other words, it’s neither common nor common. We have room for improvement in ensuring requirements are well-defined up front.

5. Can’t argue with number five. Why give one estimate on the time it takes to build a house when it’s more likely you’ll hit target with the time it takes to build the bookshelf in the library? Add up those tasks and you’ll get a better estimate overall. If the activity has five parts to it, break it down and estimate each part instead of trying to estimate the whole apple.