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.

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?