
Getting Good Estimates - mtippett
http://use-cases.org/2011/06/04/getting-good-estimates/
======
logjam
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.

~~~
mtippett
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.

