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