Betting on Story Points

  • Posted by Ian Suttle on November 15, 2008
  • Filed under Agile | Process

Welcome to part four in our ongoing quest to bring an effective agile development process to IGN Entertainment.

Something we're looking at adding to our agile tool belt is estimating stories using story points.  If you're not familiar with story points think of them as an estimation using a relative level of effort/complexity.

When getting started with story points they don't provide you much benefit beyond understanding how one story's effort compares to another i.e. "this story is a 1 and that story is a 13".  More on that later.  The real value comes as you make your way through numbers of sprints and releases.  As you progress you can look back and see how many story points a team can accomplish during a sprint.  Naturally, if the team's composition isn't constant the velocity begins to become less accurate.  The measurement of story points completed over a given amount of time is referred to as velocity.

Velocity = (Story Points Completed / Iterations)

Example: 50 Story Points Completed / 5 Iterations = a velocity of 10 story points

Velocity is handy as a means of understanding the general capacity of a team.  If a team, on average, can accomplish twenty story points per sprint, then you've established a story points budget, and you'd plan for about twenty story points for the next sprint.  That might be ten stories or that might be just one story depending on the points associated with the stories.  Taking it a bit further, using velocity allows you to estimate a release timeline using some simple math.  Consider the following formula to estimate the number of iterations/sprints before a release:

Estimated Iterations = (Story Points / Velocity)

Example: (100 Story Points Remaining / 20 Story Points Velocity) = estimate of 5 iterations

In this example, if an iteration was 2 weeks you'd have a good estimate of being 10 weeks out from release.

There's not a hard-fast rule for how to estimate with story points but we're taking a liking to Planning Poker.  The attraction is the estimates are done by the team and not by individuals.  Making a game out of it doesn't hurt either :).  If people greatly differ in their point estimates the team discusses why and re-estimates until the members of the team are close enough to just take the conservative end of the estimations.

My favorite form of story points uses numbers from what basically equates to a Fibonacci sequence (with some reasonable modifications for ease of use):

image

The idea is the higher the estimate the more risk/unknown/general the story is.  It would seem optimal to have story estimates as far left as possible as they require less effort, are more well defined, and as the major bonus, should allow for a more accurate estimate.

The application of stories points feels very promising to us.  Like everything else we add to our process it's not going to be a silver bullet but does fit in with us always looking to incrementally improve.

Have you used story points for estimating?  Has your experience been positive or challenging?

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList
Tags: ,
Actions: E-mail | Permalink | Comments (4) | Comment RSSRSS comment feed

Related posts

Comments

November 17. 2008 06:57 PM

Kenny

Good article and I'm all for using story points. With that said, I want to expand on what you have here. Unlike other units of measurement, one unit of story point cannot be defined because there is no base value to compare it to. We know how long a meter is and how heavy a kilogram is but we don't know how complex or big a story point is. This presents 2 potential problems.

1) The meaning of a unit of story point can differ among engineers because there's no baseline to compare it to. It's OK when engineers disagree on how complex a story is but not when they disagree on what "complex" means because it will affect the accuracy of the estimate.

2) The meaning of a unit of story point can differ from one project to another (assuming points are estimated at the beginning of each project). This will affect the consistency of estimates and lead to inaccurate Velocity.

To solve these problems, I suggest equating one story point to one perfect day of work by a person without any interruption (8 hours of work). This will give everyone involved a base unit to work against. It's also easier because estimating complexity by the amount of time it takes is not a new concept. Although story point is not supposed to measure duration, a complex story usually take longer to complete so one can argue that the relationship between complexity and duration is proportional. For that reason, equating story point to time required is not a problem. Thought?

Kenny

November 17. 2008 10:23 PM

Ian Suttle

@Kenny - Thanks for the comments. I think this is a common impression of story points... and they certainly have some reality attached to them. What you describe as a problem of "one unit of story points cannot be defined because there is no base value to compare it to" is actually part of the value of points. You define the value to compare it to over time based on historical accomplishments. A couple of things are recommended:

1. The team should remain constant, therefore the method of estimation should remain constant. Accomplishment may vary from sprint to sprint but that's no different than any other unit of estimation.

2. Run some sample estimations amongst the team prior to planning to come up with a common estimation method. You probably won't be perfect but at least you're working from a common understanding.

The problem with equating a day to a point is there's really no difference between the two then. Imagine estimating 10 days to complete a sprint. If that really takes you 12 days then you're 2 days late. Would you then use 12 days for your velocity for a 10 day sprint? Part of it is breaking the association with a real unit of time for both perception and part of it is having a scale that widens as you move right. As you move right the unknown and risk are higher.

Anyways, good comments and I guess we'll see how it goes! Smile

Ian Suttle

November 19. 2008 05:47 PM

Ben

@Kenny

The meaning of a "unit of story point" will not often differ widely among collaborating engineers. If and when it does the difference is resolved in the planning process. Ian highlights that "estimates are done by the team and not by individuals", with regard to Poker. To that end, differences in poker scores are indicators that more communication is required. When all issues are communicated, the team is fully represented and the score is as accurate a measure as possible. Over time players will gain a common sense of what is a 1, 8, or a 100 just as we once learned that shots can be downed, pints gulped, and gallons put us on the floor.

Ben

November 21. 2008 10:12 AM

Noobsauce

Being a long time Agile advocate, I have come to better equate a story point with complexity rather than time. The problem with time is that it is never accurate. In the past when I have said, "oh that will take me 4 hours" to my manager it will always come down to my mood. Do I feel lazy today? Meaning, I can really do that task in 1 hour but I am fudging it so I can go flirt with the girl at the front desk more. Or, was I feeling aggressive and its a 6 hour task but I want a challenge myself and look like a super star to my manager.

In addition to mood, there is this demon out there that I call "Mr. Chaos". And, that bastard tends to invade everything I do. The Mr. Chaos tends to toss in any number of things to delay me. Anywhere between production critical issues to family being sick or dying. Point is, Mr. Chaos causes me to spend time on something else besides my 4 hour task. People say, "well, to solve for Mr. Chaso always buffer your estimate by 20%." I personally don't care to try in build such generalizations into my estimates on something the changes drastically from day to day. What if Mr. Chaos decides to make my originally 4 hour estimated task much more complex than originally thought? Now I have 2 choices, 1) Rush! Slap some crap code in there to meet the deadline of 4 hours to only resolve a ton of bugs in QA or 2) Tell management the schedule is screwed and you need to adjust resources, scope or time in the project to mitigate this.

Either way, it is bad if you ask me. Now switch your thought process from Time to Complexity. 1 being, "I fell this is a very simple task to code." and 100 being, "OMG! Where is Albert Einstein when you need him." Then you get the entire group together, spend some a few minutes listening to what the story is and entails then speaking out loud to the group as to how complex you think this story is. Then, when someone in the group says, "1 - This is cake." and you say, "20 - This is getting involved." Then there is something there to discuss. Either you over thought it or he under thought it. So, you discuss the misunderstanding and in the end both of you now have a better understanding of the system and the story. After this short discussion you find that really either he or you had the real answer or the answer was somewhere in the middle. Either way, the group figured out a better thought as to the complexity of the story. The other thing is, the team starts to figure out when a threshold in complexity. And, its different for every team. This threshold is the point at which a single task should be broken down into smaller tasks or stories. For example, over time the team has found any story that the group estimates it's complexity at 20 should be broken down into smaller stories that get estimated less than 20.

The other problem with using time is what takes you 4 hours to complete a task might take a junior developer 16 hours to complete. At any given point either of you could be assigned the task. So, which estimate do you go with? If we go with yours and a junior developer gets assigned the task then you just blew your schedule. In reverse, then you would be under utilized and bored.

In summary, there is way too many variables involved to make a time estimate accurate when working within a team. I found complexity is much easier to to discuss and has a lot less variables involved. It's not perfect by any means but I feel its a fair amount better than time. I mean, you can still argue that something complex for a junior developer is simple for a senior developer that has been working at the company for a while. But, the nice thing is Mr. Chaos has a lot less involvement when utilizing complexity in your estimation thought process. Mainly because there is more known factors in complexity such as you know Class A will need to use a web service to talk to system B.

Hope this makes sense as this just comes from my own practical experiences with the Agile process.

Noobsauce

Add comment


(Will show your Gravatar icon)  

  Country flag

[b][/b] - [i][/i] - [u][/u]- [quote][/quote]



Live preview

January 7. 2009 02:09 AM