
Ask HN: Do you have faith in any time estimating system? - hackerbabz
Is there a good reason to force engineers to estimate how long a ticket will take to complete?
Personally, 90% of the time I&#x27;m just making things up if I need to estimate how long a feature will take to implement. The only time I&#x27;m confident is if I can visualize the line of code that I know is causing a bug. In that case the ticket usually takes 5 - 10 minutes to fix. But sometimes I&#x27;m wrong, and that line is causing a problem because of a bigger flaw I didn&#x27;t realize.
Can I just admit I have no idea and just write down random numbers that aren&#x27;t obviously wrong?<p>Do time estimates truly exist just to make business side employees feel good? Do you see a future where companies can negotiate funding without relying on this inherently flawed (and fraudulent?) tool?
======
onion2k
Stop estimating single points and start estimating ranges. How long will
something take in the best case scenario, the typical case, and the worst
case. That way your project manager can capture the risk, which is arguably a
much more important factor than time. If a task has a high impact on the
project and there's a big difference between the best case and worst case
times (eg it's a high risk) then it needs more attention and resources.

------
starbugs
My experience with time estimates is that they generally do not work well.
Estimating complexity (as in story points) works to a certain degree, but it's
only a very rough measure. Time estimates can work when the project scope
and/or budget is flexible. Then you have a chance to make ends meet within the
time estimate you provided, but I'd consider that not being within the scope
of your question.

In my experience, the desire for a time estimate often stems from an
underlying desire for control (mostly over a budget). That desire is
understandable. As an example, if you put yourself in the shoes of a customer
wanting your car repaired, you will most likely have a strong desire to know
what it will cost before the actual repair is carried out. That desire is
justified for a number of reasons, the most important one being that you need
a basis for a decision for or against the repair. It wouldn't make much sense
to invest more than the car is worth, for instance.

Now, it's not always possible to state a price, especially if what you're
building (or repairing) is subject to uncertainty. In that case, I'd recommend
that you provide your customer (or boss or investor) with another measure of
control. In agile development, the easiest thing you can do is shorten your
cycles and give them full transparency over your progress and the ability to
stop or change direction at each product increment. This would be analogous to
the repair shop offering you a phone call after they got a better diagnosis of
the problem for which you paid only a small amount and then you get the chance
to decide again, maybe with a better estimate of the overall repair cost.

------
ntock
In forcing the estimate you must mentally walk through the process to execute.
This process alone is believed to improve outcomes (reduce procrastination,
identify roadblocks, prioritize among other tasks). I would say the estimate
is directional, and serves other purposes.

------
db48x
I like the default time tracking that is used in the FogBugz bug tracker.
Everyone estimates how long it'll take to finish each bug, and records how
long it actually took. Of course these are all self-reported, so they can be
wrong in any number of ways.

So when you ask FogBugz when the next milestone will be completed, it doesn't
just add up the estimates. Instead, for each ticket it finds similar tickets
with similar estimates, and picks from that list one of the actual reported
times. It then adds up those reported times to make a guess at a real
estimate. It then runs the same simulation 100 times to show you how likely
you are to hit various dates.

------
gavanwilhite
For projects where an estimate is very important (not pointing every story in
a sprint), I will do an 80% confidence bounds where on one end everything goes
perfectly, and the other where everything goes horribly wrong. For both, it
should only be outside the particular bound in 10% of possible worlds. Then I
take the geometric mean of the two values.

This has worked with pretty good consistency in the past. I believe that a
good deal of the value comes from factoring in the estimate where everything
goes wrong. You can also then specifically work to prevent the things you’ve
thought about going wrong from occurring.

------
dangerface
> Can I just admit I have no idea and just write down random numbers that
> aren't obviously wrong?

Seems fair enough to me, probably because thats what I do. At the end of the
day nobody knows how long it will take unless they can tell the future.

I think scope is something my estimates are missing, for example if some one
says their roof is leaking they may just need a broken tile fixed or they
might need a new roof, without a proper scope of what I'm estimating the
estimate is too open ended.

------
jperras
Would you accept a random number from your car mechanic when you bring your
vehicle in the shop for repairs?

~~~
sheepmullet
> Would you accept a random number from your car mechanic when you bring your
> vehicle in the shop for repairs?

So are you saying we should amortize the complex cases by overestimating how
long the basic tasks take?

That can work for a mechanic because it’s 100+ standard cases to every complex
case.

~~~
jperras
Are you advocating to simply spout out a random number when asked for an
estimate on how long it would take to implement a feature in an application?

