Agile Concept of the Week: Story Point

Posted by Keith McMillan

December 17, 2012 | Leave a Comment

When folks set out to estimate the amount of work they have to do for a particular user story (what’s a user story? that’s another post…), they have to decide how they’re going to estimate the level of effort. There are two popular ways to estimate user stories: ideal hours (if you did nothing else but this task) and story points. What’s the difference, and which should you choose?The most familiar way people estimate work is by hours. There are a number of problems with an hour estimate. For starters, a task that takes me one hour may take another person on the team 15 minutes, because they’ve done it before. Hour estimates are also only relevant if you assume the team is working on nothing other than the project at hand.

Another complication is the natural bias people put on an ideal hour estimate. Once they see an estimate in hours, then they are inclined to hold you to that estimate, even if they freely admit it was an estimate in the first place. “But you said 2 hours!” they’ll complain when in fact the newest member of the team gets the task, and it takes her a day instead.

For all of these reasons and more, I prefer to estimate work in story points instead of ideal hours. A story point is a “unitless measure of complexity or effort.” What does that mean? It just means that a story point is only meaningful when you compare it to other story points.  (If you really stop and think about it, that isn’t much different from an ideal hour, once you throw away the idea that there’s a relationship between ideal and real hour estimates.)

How do you use story points to determine when you’ll be done with a project? You need a velocity for the team, in terms of how many story points they complete per sprint. In order to get that, you’ll need either a few sprints to compute a velocity, or the team’s agreement on an initial target velocity if there aren’t enough sprints completed to compute a velocity (yet another guess).

How do you arrive at a story point estimate? My favorite technique is to find the simplest story in the backlog, and assign it 2 or 3 story points. Then you can estimate everything else relative to that story. “If this is a 3, what is the complexity of this other story.”

Incidentally, it’s become tradition to use the Fibonacci sequence as the values for story points. Why? Not for any magic reason, but mainly because it provides a nice step between stories of different sizes, and I think it keeps people from arguing about slight differences in complexity, since the step sizes are bigger.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.