Estimates

Estimating tasks is hard to get right. I’ll probably blog about this again in the future, but for now I’m going to give my current thinking.

You’ll hear lots of opinions if you talk to people in the software development industry. They’ll range from how important it is and how much we should focus on doing a good job of it to the exact opposite: why bother estimating at all since we do such a poor job of it?

I used to give estimates with various resolutions: 1 hour, 2 hours, 1/2 day, 1 day, 2 days, 3 days, 4 days, etc. I don’t see the value in this level of specificity any more.

My new strategy, and this might last a whole week, is to give estimates where the categories are “exponential”. I’m struggling for the right name for it, but suffice to say, each category is considerably larger than the previous. For example I wouldn’t give an estimate with any more resolution than these: 1 hr, 1/2 day, 2 days, 1 week, 1 month.

When creating the estimate, I consider the risks and unknowns and attempt to understand the impacts. Some of the major impacts include: data model changes, UI changes, engine/rules changes, potential regressions, how many tests need to be modified or created, and impacts to the build process. I’m sure you can think of more. The more impacts, the larger the estimate. The more risks and unknowns, the larger the estimate. And I also attempt to mold the estimate to the person who will likely be doing the work. If I don’t know who that person is, I’ll increase the estimate.

One final point of note is that developers often don’t particularly like it when you give estimates on their behalf. It’s good to get buy-in from the person who will get the assignment if you can.

Leave a Reply

Your email address will not be published. Required fields are marked *