The Art of Estimating

If we could assign perfectly accurate estimates to the time needed to fix bugs and implement features as soon as we knew about them, keeping a software project on track would be much simpler. Alas, in the real world it doesn't work that way. Initial estimates are frequently wrong and need to be revised as work progresses. In fact, as a profession, we're so bad at estimating (especially on large projects) that many software projects never get finished at all. Instead they're cancelled amidst a general atmosphere of slipping schedules and rising costs.

The good news is that there are ways to improve your estimating ability. If you consciously practice and put thought into making good estimates, you can get better at it. Although estimating will always remain an art rather than a science, here are some tips that you can use to improve your estimates:

• When entering cases (especially features), strive to make them cover as little as possible. The smaller the task, the better you'll be able to estimate it. For example, "add Web integration" is hopelessly broad, and any estimate the developer makes will probably be wildly inaccurate. "Implement uploading log files via FTP" is a much more easily estimated task. Some people call these fine-grained tasks inch-pebbles to indicate that they're much smaller than milestones.

• While a manager may enter an original estimate based on a project plan, the actual estimate must be owned by the developer who's actually doing the work. You can't get a 10-hour feature done in 5 hours simply by chopping the estimate in half.

• Keep all the work that has to be done in a single system (such as FogBugz!). If there's a place to estimate every task, developers will be less likely to pad estimates to include time for "off the books" work. When you run into a new task that's not on the project, take the time to enter a case for it.

• After you've been entering estimates for a while, take the time to review the original and final estimates on your own closed cases to look for patterns. If you consistently have to add 50% to your original estimate, for example, you should adjust your original estimates by 50% when you make them. Almost every developer is too optimistic when they start estimating the time that it will take to fix a bug or implement a feature.

• Keep the schedule up to date. You should update the current estimate and elapsed time on all of your open cases once a day in most cases. These continuous small course corrections will help you zero in on accurate estimates.

• If one developer's estimates are wildly inaccurate, have them work with an "estimating mentor" in developing estimates for new cases.

• Don't use estimates to hide a disaster. If you're falling behind, it can be tempting to reduce the estimates of the work remaining on your plate so that your manager doesn't get worried. Perhaps you think you'll catch up by working extra hard. You won't. If there's a problem, it needs to be out in the open where the whole team can solve it, if necessary by reassigning features to other developers or even cutting them. Think of it this way: would you rather look slow but honest six weeks before the beta, or be the person who prevents the beta from going out on time when your poor estimates finally become obvious the week before it's due to ship?

• Don't gold-plate your estimates. If you build in excess time so that you can surf the Web, call your broker, and sleep late, your manager will eventually notice just by looking at the number of features you implement compared to the rest of the team. It's better to estimate as accurately as you can and ask for slack time when you need it.

■Note For a more detailed look at the entire project planning process, see Joel Spolsky's essay "Painless Software Schedules," reprinted in Joel on Software (Apress, 2004).

0 0

Post a comment