MT

One of my favorite agile planning techniques is to use story points for story estimation. In a nutshell, story point estimation means the team decides on the size of the story, rather than how long it will take to get the story done. The size of the story is represented by a unit of measure that is decided upon by the team. You could use units like [tiny, extra small, small, medium, large, extra large]. I personally prefer numerical sizes like [1, 2, 3, 5, 8, 13, 20, 40] that spread as the number gets higher. The idea is it should be a unit is not described by time (i.e. hours or days) but is defined by its relation to itself (I'll explain what I mean by that a little later).

Whenever I've introduced this concept to developers, it usually goes something like this:

Tom: "So if you're saying we should estimate in story points, how long is a story point?"
Me: "How long is a mile?"
Tom: [Blank stare]
Me: "A story point isn't something based on time, but rather on size. You wouldn't tell me that a mile is about 1 minute would you?"
Tom: "No."
Me: "Why not?"
Tom: "Because how long a mile is in terms of time depends on your velocity."
Me: "So based on what you just said, how much time it takes to complete a story point depends on the team's velocity?"
Tom: [Pause] "Yeah, I suppose so. But when you ask me how many story points I think a story is, how am I supposed to know the answer if I don't know what a story point is."
Me: "We all find a story that we choose to be 5 story points, and estimate the other stories relative to that one. If the next story seems like less effort, then give it a number less than 5; if it's more effort then give it a number more than 5. A story point is defined by it's relation to other story points."

Even after this discussion and during planning poker I hear people saying things like, "That one isn't a 5, there's no way you can get that done in 5 days!". I have to constantly remind people to stop thinking about the stories in terms of time. What's interesting, is that the people that have this problem are those that have been working with the code longer and have been doing estimates in hours for a long time. The new guys don't have any idea how long it's going to take to write code within a system that they've had very little exposure to and therefore are left with only estimating effort relative to other efforts.

I had a developer whose first day on the job happen to be our planning day. His manager was telling me that he should just observe because he doesn't have any basis for estimating the work yet because he's new. I disagreed and said if he's part of the team, he's part of the team and he estimates with us. We do planning poker so there's no way his estimates were being influenced by others. When it came time to show cards, his first few estimates were not inline with the team. However, after a few stories he was able to pick numbers that were in line with the team; you never would have been able to tell that it was his first day.

I've seen the above incident happen on more than one occasion and believe it's a good indication that story point estimation is a fast and reliable way to estimate stories. But how is this used outside of iteration planning and into release planning? The product owner should be looking at how many story points were burned during an iteration to get an idea what the teams current story point velocity is. They can then use this velocity to figure out how many iterations it's going to take to complete a given set of stories. For example, if my team burns 100 story points an iteration on average, and I have 550 story points worth of stories in my backlog, I can reasonably say that it'll take 6 iterations to complete all of those stories. If the iterations are 2 weeks each, then I can tell upper management that the next release is 14 weeks out (6 iterations * 2 weeks each = 12 weeks + 2 "just in case" weeks).

From my experience, the concept of story points, velocity, and release planning are something that untrained product owners know little about. They keep trying to do funny math with story points to come up with hours per story point then use those hours to plan longer term goals; not once looking at the team's actual velocity. I'm not a product owner and will admit that I don't understand the level of pressure that comes from the business, but I do know from experience that using story points without understanding how to plan releases with them, has caused frustration and tension between the development team and the business.