
Ask HN: Should developers provide time estimates? - timurlenk
We have debate in our company - who should provide the estimation for the duration of a task (usually part of a project). I have seen a few popular options:<p>- the developer who will implement the task (a somewhat prevailing opinion on the internet)
- senior developers
- project managers<p>Thinking about it a new option may have emerged: estimates should not really be needed; and I would like to explore this option below.<p>Let&#x27;s agree first that estimates are mandated for various business reasons but we won&#x27;t require greater precision than a day of work.<p>Now, doing a thought experiment we analyse if there would be any estimate difference for a task requiring one line of code or &quot;Hello World!&quot; and agree that no matter who would provide the estimate the answer will be the same - probably the smallest unit of estimation since the task is trivial and the solution is canonical.<p>Going forward, however we agree that there is a point where estimates will diverge even between the most seasoned developers and estimators. I would argue that in that point the divergence stems either from a difference in understanding of the problem or different approaches in solving the respective (complex) task. Since both scenarios could cause problems down the line in the project, the team should step back, clarify the requirements &amp; approach to the solution and break it down into further tasks that are trivial enough to be executed in the smallest unit of estimation.<p>In summary, estimation is the wrong problem to solve, the team should spend the time to thoroughly understand the requirements and truly define the solution approach, leaving the time estimate to be just a matter of counting the generated tasks and multiplying that with the agreed smallest unit of work.<p>While the above is a hypothetical scenario, what are your thoughts around it? Where do you see its flaws and where do you see its merits? Is anyone doing such a thing or was it tried and failed?
======
karmakaze
There are different kinds of estimates used for different purposes. When
making an estimate, know what it's for and if it has any value at all or can
be omitted.

Very high-level estimates can be used to decide whether to do one project or
another. Here we're both guessing time/cost as well as expected value. If
unclear do some work to make better guesses of time/cost or expected value.

Estimates can also be used go co-ordinate with other teams if there are
scheduling dependencies. Communicate early and often. Do some work to validate
estimates. Complete tasks in a way that makes other estimates more accurate.
e.g. deploy the smallest feature to prod with all steps completed rather than
100% of scope 10% done. If it's an external team, make your best guess, leave
some room and aim to be early because you won't be.

Estimates to fill plan/fill work weeks are mostly a waste of time. Instead
identify what's important, break them down into small parts with the
immediately sequenced parts in higher resolution and do as many as you can in
a natural order.

You can still schedule tasks expected to be completed in a cycle but it's a
direct assessment as in "I can do items 1 & 4 in the next two weeks" not an
abstract each item got a team-agreed T-shirt size and you've been selected to
do these ones that add up to 10 days.

------
timurlenk
There is a secondary discussion if developers should be accountable for
sticking to estimates, and my opinion is that they shouldn't - developers
should be accountable for the quality and maintainability of the produced
code, documentation and tests, not timelines - that's the job of the PM. A
good PM will be able to observe that on average the unit of estimation takes
20% longer or shorter and adjust the project timelines accordingly. Also, if
someone is worried about developer productivity, it can always evaluate it in
relative terms, i.e. how many tasks generated with the above method does one
developer execute vs another developer in the same unit of time.

------
chrisbennet
There is a fair chance I maybe an idiot but I've rarely worked on a problem
where I could:

 _" thoroughly understand the requirements and truly define the solution
approach, leaving the time estimate to be just a matter of counting the
generated tasks"_

The problems I've been paid to solve are problems that haven't been solved yet
or at least _I_ have never solved them before so I would have difficulty
making a estimate.

(This isn't meant as a criticism. It's just my experience.)

------
analyst74
Is your company requiring hour or even minute accuracy of the estimate?

In my whole professional life, I have not been put in such situation, even
when working as consultant where we charge by the hour -- we simply estimate
by week or day then multiply.

The art part of estimation is setting expectations, or more precisely, adding
and justifying buffer time, and form an acceptable narrative when the schedule
deviate from plan.

~~~
timurlenk
I mentioned that no greater precision than a day of work is required. The
point of the question is not precision, but who and possibly how.

