Getting Good Estimates

use-cases.org

2 points·mtippett··2 comments

When managers request software estimates from engineers, engineers should frown, look them dead in the eyes, and tell them that making estimates is a managerial/administrative task.

Managers should collect, maintain, and have access to substantial historical data upon which they can make estimates and other administrative trivia. What else are managers for?

Of course, what engineers need to understand is the game at work here: making an estimate is primarily about making you commit to a date, with which you will be flogged by those asking for such an estimate.

Your job is to solve problems - not to make estimates, nor to be flogged.

It's a relationship. Managers shouldn't choose a date, they should come to an understanding with the engineer doing the work. The whole point of the discussion and the range is to discover what could go wrong and pro-actively look to mitigate that.

Managers help manage, the discovery of risks and issues that I talk about in the article are where the manager comes in. The identification of the risks, inter-dependencies, unknowns and so on inherent in the task comes primarily from the person doing the work. I believe this is part of the "solve problems" that you talk of.

Engineers should have no concern working through an estimate with their peers or their manager (be it direct line or part of the project).

Neither engineers nor managers should be asked to deal with unrealistic or overtly broad indications of a date. In the article I talk about a range and a confidence. If there are strong unknowns, that can't be determined, then that is risk that is carried within the task. That is part of the problem that needs to be solved.

I don't believe I talked about commitment, flogging or anything else. I am talking about planning and discovery.

Reply on news.ycombinator.com