I have had occasion in the past few years to participate in several different teams that were cutting their teeth on agile and Scrum for the first time. One thing that always seems to trip people up when they are first learning about agile is the concept of a “Story Point”. In this article I’m going to attempt to add some clarity to what story points are, what they aren’t, and how they should be used in agile project.
NOTE: I am going to stick with the term “agile” throughout this article. There are many different flavors of agile, some of which use story points, and some of which don’t. I’m most familiar with Scrum, but I think story points can be used just as effectively outside of Scrum. If you feel very strongly that I am screwing up the terms and damaging the universe, and that you need to set me straight, I encourage you to grab a beer instead.
Invariably, when someone who “gets” agile tries to explain it to someone who is uninitiated, this conversation eventually plays out:
Agilista: Stories are estimated with story points.
Initiate: What is a story point?
Agilista: A story point is just a number. It is a relative measure of the size of that story.
Initiate: So many hours are in a story point?
Agilista: There is no translation from story points to hours. A 4 point story might take 2 hours or 20. It depends on the team and the project. The only thing that you know about a 4 point story is that it is double the size of a 2 point story.
Initiate: Umm…so if I have a 3 day task, how many points is that?
Agilista: I need a drink…
There are a number of misconceptions that surround story points, and they are all interrelated. But let’s try to take them one at a time.
Story points measure size, not time
The question “how many hours is 3 story points?” is nonsensical in the same way as the question “how many minutes is 3 buckets?”. People are used to tracking projects using time units such as hours or days, but story points are measure of size. Size is an ambiguous term, and depending on the project can incorporate different things, such as number of units, complexity, technical risk, etc. In a UI-centric project, story points might correlate to number of widgets on a screen. In a database-centric project, they could correlate instead to number of tables or columns.
The analogy I like to use (which I’ve shamelessly stolen without remembering the source) is painting a house. If my wife and I want to paint our house, we might not be able to accurately estimate how long the project will take us. And, in fact, I might be a much slower painter than my wife, so depending on which of us ends up painting a particular room, it could take different amounts of time to finish it. But, it would be pretty easy for us to judge the size of the rooms relative to one another, and assign them point values. We would end up with something like this:
This list doesn’t tell us how long it will take to paint the full bathroom, but it does tell us that the living room should take roughly four times as long as that. Over time, as we start painting, we will start to understand how much Painting Points we can get through in a weekend. In fact, after a few weekends, our Painting Velocity will probably increase as we start to get some expertise, and a Painting Point will go quicker than it did before. But as long as we keep track of our Painting Velocity and our Painting Burndown Chart, we’ll know how many weekends we have left before we can finally invite the neighbors over.
Story points are used for stories, not tasks
One common reaction to story points is that they can’t work because at some point you need to make sure that you aren’t planning to do 80 hours of work in a 40 hour work week. This is especially important to the person who is assigned to do that work. Agile does address this, but at the task level, and not at the story level. With agile, you don’t worry about the tasks that are required to implement a story until you are ready to actually work on that story. This saves a lot of time, because a lot of stories are never implemented, or they change drastically from the time they are first envisioned to when they are actually delivered. So detailed task planning for stories that won’t be done for months can result in a lot of wasted time.
In a sprint planning meeting, the team starts by choosing a bunch of stories to include in a sprint. The sum of the Story Points of those stories should be roughly equal to the team’s velocity. However, beyond that, Story Points don’t really matter in sprint planning. The team looks at each story and comes up with a list of tasks. Tasks are estimated in hours and are assigned to individuals. This allows for load balancing across the team, and can be used as a sanity check to make sure that that team isn’t biting off more than they can chew.
Story Points are more useful for high level project planning. They are used in release planning and project burndown to figure out roughly how much work is involved in a given set of stories. But once a particular individual is doing a particular task, there is a time-based estimate for that task.
What is with this Fibonacci thing?
I have actually been in meetings where a half dozen bright, engaged, highly-paid people have debated whether a task that isn’t well defined, won’t be done for sixth months, and hasn’t been assigned yet, will take 40 hours, or whether it will really take 48. This kind of imaginary precision is common in waterfall estimation processes. To combat this false precision, Story Point estimates are commonly constrained to a set of values that get less precise as they get larger. The bigger something is, the less important it is to know exactly how big it is.
You can see a similar effect in golf. As any golfer knows, it is very important to correctly estimate the result of a putter stroke to the scale of inches. But no golfer spends time estimating whether his next drive will go 220 yards or 220 yards and 3 inches.
The scale I see used most often for story points is this: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. (For any mathematicians in the audience, I know this isn’t exactly the Fibonacci sequence, but it works.) Using this scale, it is simply impossible for a story to be 27 Story Points. It is either 20 or 40, because at that scale it isn’t possible to estimate at that granularity with any level of confidence. And it doesn’t matter in the long run, because most projects will end up being many hundreds or thousands of points in the end, so this stuff becomes rounding error.
When you use the Fibonacci sequence with Story Point estimation, you don’t have to watch your life tick away as two of your teammates endlessly debate whether the Widget Frobbelizer is 20 points or because of the Gadget Goozler requirement it should actually be 23. And that is well worth it.
Getting started with story points
At this point, hopefully I’ve clarified what Story Points are, and why they are useful when doing agile projects. If you have a bunch of stories that are already estimates with Story Points, it is pretty easy to figure out where a new story fits in that scale. But how do you get started with Story Points at the beginning of a project? How does a team decide what 1 Story Point should mean for that project? I’m sure there are lots of different ways to get started with Story Points, but two stand out that I see most commonly in the literature and out in the wild.
Use a “Keystone Story”
This method is pretty simple. After the team has created the initial backlog of stories for the project, pick one of those stories that is a good representation of an “average” story from that list. Call that story an 8. Then, estimate all of the other stories relative to that size 8 average story. That is how I arrived at my list of Painting Point estimates above: I figured that the living room was a pretty representative room in a house. I called that an 8 and estimated relative to that for all of the other rooms.
Use “Ideal Days”
Imagine a perfect work day, where you are totally on your game, everything goes smoothly, no one interrupts you, they have your favorite meal in the cafeteria, and that annoying jerk two cubes down took a sick day. Now, imagine how much work you could get done in that day. Call that amount of work 1 Story Point, and estimate your backlog relative to that 1 Story Point ideal day.
It isn’t a big deal which of these methods you use, or if you use a different method instead. Once you get over the hump and have a few stories in your backlog with estimates, you don’t really need to worry about what a Story Point “means”. Your estimates will start to get quicker and better as you have more and more examples to compare to. The team will start to get used to the process and what the value of a point is for that project, and you will be well on your way to a successful agile project.