How You Can Improve Estimate Accuracy

Before we pull off the road and head for dinner, we're going to look at some more things you can do to help improve the estimates. The start of a new release is lot like a going down a good buffet line: all the stories look good. The team wants to make the customer happy, and programmers tend to be (and we are, and have been, programmers too) incorrigible optimists. We can't resist taking some of every dish, and we tend to overestimate our velocity.

You can help offset this tendency, but you need to be diplomatic about it. Nobody likes dieting, and the last thing you want to do is become an adversary. We've chosen the term enable to suggest that what you're doing allows others to be more accurate instead of somehow forcing them to be. Once again, a tangential approach is best.

You can, for instance, challenge estimates (politely): "Are you sure you can do that story in one day?" This is much preferable to challenging the estimator, as in, "Carol, there's no way you can get that done in one day, and you know it."

You can also point out aspects the estimator may have overlooked and allow her to draw her own conclusions. You can do this without making her feel stupid. For instance, "Carol, when you made that estimate, did you realize category names and codes don't have a one-to-one relationship?" may make Carol defensive if, in fact, she did overlook it. A better approach might be, "You know, Carol, I didn't realize until now that category names and codes don't have a one-to-one correspondence. Does that have any impact on how long it will take?"

When all else fails, play dumb and have someone (preferably the customer) explain things to you in the presence of the estimator. This gets the information to the estimator and lets her absorb it and take it into account while everyone is focused on you instead. Don't do this too often, though, or it will undermine your credibility.

This process begins in release planning, as soon as a story is written, but continues as the project progresses. You can ask in every daily standup meeting, where team members discuss their progress (we discuss standups in Chapter 30), "Are we sure we can finish all these stories? Do we need to go to the customer and have him remove a story?" And you can make a pest of yourself in other helpful ways: "Don't forget, these stories have to be finished the day before the end of the iteration, so we can run all the tests on the completed packages."

Please note that we encourage the use of the pronoun we in these questions. You don't want to exclude yourself from the problem. Not only will this cause resentment, it just isn't true. You're just as likely to be overly optimistic when you estimate, and you have to be diligent in keeping your own estimates realistic.

Another technique you can use is to question estimates that differ significantly from each other when the stories seem similar. For example, "I don't understand why the estimate for story 3 is twice that of story 2 when it seems they ought to take about the same amount of time. Is the estimate for story 3 too high?" Do look for estimates that are too high. They're rare, but watch for "padded" estimates that have been inflated for no valid reason. Your goal is more accurate estimates, not just higher ones.

Accurate estimates are important, but unfortunately, we don't have an algorithm we can give you to get you started. You'll acquire these communication and "people" skills by working with team members individually and in groups. The best we can do is suggest a few guidelines:

• Challenge the estimate, but don't get personal.

• Point out things you think were missed but not who missed them.

• Phrase comments in terms of "how long it will take," not "the estimate" or "your estimate."

• If someone has to look stupid, make sure it's you, but don't do it often.

• Question widely differing estimates for stories that seem similar.