Story Estimation
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
Ron Jeffries expresses the strongest view on the matter:
Estimates are not a good thing in most organizations: they are used as commitments and bludgeons. They also lead to a mechanistic approach to deciding how much work to take on, adding up points or hours, rather than a deeper look at what the team can accomplish, and how.
[...]
I recommend not estimating stories at all, beyond making them all "a couple of days work for a couple of people". That is, of course, still a kind of estimate, but not one that is easy to misuse.
[...]
I like having the team estimate the big stories in weeks, then add them up. What this will do is give a general sense of the size of the project. THIS CANNOT BE A PROMISE, but it can be a point at with you can ask the important question, which is something like: With N dollars and M months, can we get something worth shipping?
Source: http://www.infoq.com/news/2011/01/scrum-project-estimation
"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
Story points pitfalls: Stop Using Story Points by Joshua Kerievsky: http://www.industriallogic.com/blog/stop-using-story-points/.
Why not to use story points: http://tech.groups.yahoo.com/group/scrumdevelopment/message/56016 by Ron
TODO: snatch quotes
Why not to communicate hours to the customer: http://tech.groups.yahoo.com/group/scrumdevelopment/message/56016 by Ron