The best people to create the estimates are the ones who do the work

From Project Manager 97Things

Jump to: navigation, search

The Best Estimators – Those Who Do The Work

Joe Zenevitch New York, New York, USA

Have you been on a project where one person creates all the estimates for the work to be done? Has this been a successful approach? My guess is, probably not.

There are three major problems with this approach.

1) Unless you are lucky, the developers on the team will not be at the same skill level as the person creating the estimates. So, while the estimates might be accurate if the lead architect was doing all the work, more than likely the developer’s paces will vary.

2) The risk that one person estimating for the entire team will be incorrect is pretty high. The more people involved in estimating, the better.

3) Developers are going to be handed an estimate they must meet. Rarely have I seen a developer who is happy with this approach.

The worst infraction is when you, as the software project manager, decide you are qualified to provide the estimates for the team. You may think that since you were a former developer you can adequately choose the estimates. Even if you are still actively doing development, think again. The same issues apply as with the lead architect above, but the longer it's been since you've done active development, the worse your estimates are going to be. And don't even think about estimating if you are leading a team using a technology with which you are unfamiliar.

On our projects, we do group estimation using a wideband-delphi approach. We start by having our business analyst describe the requirements for a feature, the development team listens, and then they ask clarifying questions. Once they are ready to give their initial estimate, they each write their individual figure on a card. When everyone has finished, on the count of three they all hold up their cards.

Now we see how they compare. If they are very close, we go with the more conservative number. If there is a wide discrepancy, we ask the developers to talk about the assumptions that went into their estimate. After more discussion, we ask them to estimate again. What happens most frequently is that the estimates converge to a single number as the developers gain a common understanding and agreement on what will be required to complete the feature.

This approach is advantageous because:

1) All of the team is involved in coming up with the estimates and all varying perspectives are shared. Often they are all of one mind and can get to a shared estimate quickly.

2) Later when actual coding begins, developers will all have had exposure to the thought process that went into coming up with the estimates, making it less necessary that only certain people can work on any one feature.

3) By having the team "own" the estimate, there is less chance of backlash. Their estimate may still be wrong, but they will be less confrontational about it and more cooperative in coming to a revised estimate.

Remember, the best estimators are those who will do the work.

Personal tools