

Ask HN: tips for improving scheduling estimates? - kennon

I'm part of a very young team of about 10: 7 engineers, 3 product/design. This is the first or second real programming gig for most of the engineers; product side is a little more experienced, but not by much. One thing that we consistently run into is poor scheduling estimates-- something takes just a little bit longer than expected, and this has a cascading domino effect that far exceeds the initial misstep. We've tried to apply the old adages-- take your best estimate and double it, remember that the last 20% of a task takes 50% of the time-- but things still seem to unravel with each sprint.<p>It seems like estimating time is one of the less talked-about skills of the engineer, but one that's at least as important as cranking out good code, and maybe harder to master. So for the more seasoned engineers out there, or anyone, really: how did you learn to look at a project, break it down, and attach time to the pieces? I find our team struggling with 2-week sprints, but there are clearly people planning things out months in advance-- what steps do you take? What about making or validating estimates on aspects that you don't have expertise in (for instance, estimating a front-end task when you're mostly on the backend)? When starting with no history, how many weeks of concrete scheduling data do you need before your estimates begin to hold water? And on the softer side, how do you (gently) nudge someone in the right direction if they are consistently off in their estimates?<p>Lastly, a couple ideas I've heard of but never tried:<p>- Planning poker: http://en.wikipedia.org/wiki/Planning_poker<p>- Use fib when assigning hrs to tasks: 1, 2, 3, 5, 8, 13h etc<p>Anyone use these with success? Perhaps suggestions for lightweight project management tools?
======
knowsnothing613
I remember a lecture where my prof said the multiply by 2 never works out for
project management, because studies have shown that workers find ways to
prolong the project twice as long.

For instance if you knew your homework was due 2 weeks from now, instead of a
week, you find a way to procrastinate for the extra week.

Instead try PERT

[http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_T...](http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique)

And try this formula:

    
    
        * Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected
        * Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).
        * Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.
        * Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time).
    
                TE = (O + 4M + P) ÷ 6

------
thibaut_barrere
Here's what I use and recommend:

* Mike Cohn resources were the most helpful to me:

\- free presentations around estimating and planning (eg:
[http://www.mountaingoatsoftware.com/presentations/131-agile-...](http://www.mountaingoatsoftware.com/presentations/131-agile-
estimating) and others on the same site)

\- the "Agile Estimating and Planning" book ([http://www.amazon.com/Agile-
Estimating-Planning-Mike-Cohn/dp...](http://www.amazon.com/Agile-Estimating-
Planning-Mike-Cohn/dp/0131479415))

\- Mike Cohn "Agile Estimating and Planning" course (2 days) was worth taking

* Software estimation: demystifying the black art ([http://www.amazon.com/Software-Estimation-Demystifying-Pract...](http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351)) is a very useful book too

* For lightweight project management tool: I use a mixture of Acunote (for estimating and burndown chart - I even generate my quotes out of it using Ruby and Prawn) and Freckle to monitor the time spent.

I tried many other tools (including Mingle, Pivotal, etc...) but Acunote is
the only one that works well for us.

------
younata
"However long you expect it to take, multiplied by four" - Paraphrased from
Scotty.

All joking aside, my "custom" (as in I came up with it on my own, others
probably came up with it as well) system is to break down the task as much as
possible, then depending on how complex they are, give each subtask either an
hour or a day. Then, multiply that amount of time by four.

~~~
timrobinson
+1 I use the same approach: repeatedly split the task into smaller tasks until
you've got a list of tasks all the same size. I don't think I've estimated
down to less than half a day, however: I've never been comfortable coming up
with fixed hours-per-day number for the team. (As long as you can get enough
work done in a 24-hour period, and I can get hold of you when I'm in the
office, I don't care when you do it.)

However I'm not entirely comfortable with applying fudge factors like
"multiply all estimates by four". I'd rather try to gauge the confidence that
we have in our estimate: either by planning poker, or by coming up with
separate worst case, best case and expected estimates.

------
RiderOfGiraffes
Clickable: <http://en.wikipedia.org/wiki/Planning_poker>

With regards helping people make their estimates better, make them visible.
What gets measured gets managed, and people can't improve unless they can see
the target. Make a note of their estimate, and compare against the time it
actually took.

You can make this "public" within the company, or you can keep it between just
a few people, but you must make it visible. Most people will self-correct when
given the data.

------
kenkyhuang
The Mythical Man Month, although old, has some great tips for estimating
software engineering work.

[http://www.amazon.com/Mythical-Man-Month-Software-
Engineerin...](http://www.amazon.com/Mythical-Man-Month-Software-Engineering-
Anniversary/dp/0201835959)

------
fbnt
During my corporate gig, we engineers had a non-written rule of thumbs to
estimate sheduling: Think about how much time do you really think it will take
to do it, double it, and add 20% contingency. This worked well most of the
time, as usually we tend to be far too optimistic.

------
revorad
Evidence based scheduling -
<http://www.joelonsoftware.com/items/2007/10/26.html>

