Proper story estimation - beyond story points.


"I speak with some authority on this: on the original XP project, we
used absolute estimation, invented "perfect days", encountered
hidden adjustments, and finally invented the notion of abstract
points. Abstract points don't work very well either.

What comes close to working is to make stories about all the same
size, "a couple of days work", and count how many you get done. Use
that to project what will happen.

Penultimately, it is worth mentioning that Chet and I (both on that
first XP project, you'll recall) no longer recommend story
estimation at the Sprint level at all. We recommend that teams do
what Scrum always used to say they should do: The Product Owner
lists stories in priority order, and the team draws a line at how
much they think they can do. Then Inspect, Adapt, Improve."

Source: http://groups.yahoo.com/group/scrumdevelopment/message/49518 by Ron Jeffries
http://groups.yahoo.com/group/scrumdevelopment/message/51171

"Right. Teams that are brand new to Agile need to do something to achieve
Goldilocks sizing (i.e. what's too big to fit in an iteration, what's too
small to track, and what is just the right size.) But once we have developed
the skill to reliably size thing we can always break down the things that
are too big, reintegrate the things that are too small, and get everything
right sized (1-5 or whatever we call it.) Then you can just assume that
every story will take an average amount of time. You will still be wrong
sometimes, but that is unavoidable (And, yes, this is an application of CLT,
albeit a very informal one. I have never proven that story sizes
consistently follow a normal distribution, only that the variation can be
kept small enough to allow us to pretend they do and still predict similar
results.)"

Source: http://groups.yahoo.com/group/scrumdevelopment/message/52147 by Adam Sroka