HN Explorer

Ask HN: tips for improving scheduling estimates?

6 points by kennon ↗ HN
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.

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?

Lastly, a couple ideas I've heard of but never tried:

- Planning poker: http://en.wikipedia.org/wiki/Planning_poker

- Use fib when assigning hrs to tasks: 1, 2, 3, 5, 8, 13h etc

Anyone use these with success? Perhaps suggestions for lightweight project management tools?

8 comments

[ 3.6 ms ] story [ 29.9 ms ] thread
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.

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-... and others on the same site)

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

- 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...) 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.

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

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