Sunday, March 26, 2006

Hours vs. Story Points

In my talk, I briefly described User Stories and Story Points. I could have easily spoken for an hour on User Stories, but I could only spend a few minutes. To highlight, User Stories are:
  • Feature descriptions from anyone on the team or any customer.
  • Use a simple template to insure correct communication.
  • Have "Conditions of Satisfaction" which are things that can be seen or tested in the review.
  • Are estimated.
  • Are not dependent on other stories.

One of the key values of User Stories is that they can be estimated. Estimations are made using "Story Points". Story Points are a relative measure of feature difficulty/complexity that are useful for planning. If one feature takes twice as much effort as another, it will have twice the story points. As it turns out, Story Points are a more accurate measure of project velocity and release schedule than using hours and days.

"Hours and days" attempt to not only estimate the effort of a feature, but also the velocity of the people working on it. With Agile Planning, we separate those two measures. We estimate the effort of the feature in isolation and emperically measure the velocity of a team that is doing the work. There are many benefits of doing this. They are separate numbers that come from separate factors!

One major benefit of estimating stories is using the "poker game". The poker game is where the team and customers get together and discuss the stories. Each story is discussed and then each person at the meeting raises a card that shows how many story points they feel should be assigned to the story. The first vote usually shows a wide variation of points. We then discuss the estimates (usually the high & low voting people talk first). This is very beneficial because the unknowns and assumptions are revealed. People take very different views of a feature and this leads to wide variations of expectancies when the feature is estimated. All of this comes out in the discussion of the story being estimated and some of the points make it in as "conditions of satisfaction" for the story.

This process is repeated until the room is pretty close on what the points should be and then we move on.

To estimate an entire release (4 months) of stories took a dozen people an entire day (we had to go offsite so we wouldn't be interrupted). We also have "lookahead" planning sessions where the entire team gets together about once a month to refine the stories (disaggregate larger stories into smaller ones) and estimate those stories.

The end benefit is that teams get a consistent story burndown velocity that allows them to see how well they are tracking their release goals (measured once every 2-week sprint). This is the velocity of real feature development that is far more valuable than estimated hours.


Anonymous said...

Nice article. I've used story points in the past and prefer it to real time units, but find that some team members just can't deal with abstract points.

Question: How do you set your velocity for your first sprint? Typically, we just make a reasonable guess and then adjust. Just wanted to see if there was a more intelligent way of doing it.

Clinton Keith said...


The team will take on a number of stories and break them down into estimated (hour) tasks (Sprint backlog).

Anonymous said...

Interesting post - how have you found the team take to stories? was there any pattern to who 'got it' and who took longer?
I really like the focus a story can give you - on the user experience & goal. We have been working with them on my current project but have not been using story points to size work.

How do you cope with different disciplines working in story points? Agile theory tends to be very engineering centric and games are very diverse.

Clinton Keith said...

Stories are usually cross-displine anyways. Stories that are "programming only" are less frequent. Usually the conversation on points is useful because one discipline will hear how hard it's going to be for the other and offer quick solutions (e.g. the artists may want some complex tool, but when they see what they lose from other stories might horse trade for something 90% as effective that takes 50% of the time)

Mark Levison said...

Great description of Story Points. I just made reference to it in my post
"Scrum in a Nutshell"

Anonymous said...

What are end users supposed to make of story points ? Do you ever see them thinking about IT deliveries in anything other than cost and delivery date ?

Clinton Keith said...

End users won't care about story points. Publishers can care about story points as they are used for forecasts of release feature set and discussions on those.

Anonymous said...

Story Points are all about planning and forecasting. By the time the product gets to the end user the points have been completed and aren't a topic to publicize.

I've posted on story points with a bit more general thought behind it if interested.

Jolyon Wharton said...

Thanks Keith for you time in putting this up. I've 10 year experience of XP, using it while it was still a set of white papers. I've never understood story points and feel they are unnessarsery if proper feedback machanism are in place to check estimates. IMHO this is a level of astraction not required, everyone knows what time is. The planning game should be played with domain experts and senior technologist and therefore esitamtes should have a 80% confidence or higher. If they are wrong this is feedback to the next planning game. In fact you still have to put time against you SBI's anyway, all story points are, in my mind are a matrix for messuring volocity. They tell you nothing about the time it will take to implement a story. Once again many thanks for your time.

Clinton Keith said...

Hi Jolyon,

Thanks for the comment.

Yes, story points are not commitments to time. They are not ties to individuals. As you indicate they are not sufficient for commitments. Their value is for forecast based on velocity. Over a longer term (2-3+ months) they are very consistent however....more-so than time estimates.


Bhushan Bhangale said...

Nice simple explanation. If I give 2 points to a story then on what basis I give the same point to another story? How do I guess that two stories will take same time? Isn't I need some kind of quantification? Number of days is one quantification?

Clinton Keith said...

Hi Bhushan,

Points are a relative measure of the effort required to complete a story compared to another, so if you think two stories will take the same amount of time, then they should have the same points.

In planning poker, or some other collaborative cross-discipline exercise to determine points, the discussion will compare stories, use triangulation, disaggregate stories, etc. to produce the best estimate. It won't have the same accuracy as the estimates of time given at Sprint planning, but we can't estimate the entire backlog in's too great a time-range to estimate out...