User Stories and the Backlog: Story Points

A story point is a relative unit of measurement for user stories, bugs, spikes, and other less-common backlog items such as tasks addressing technical debt, engineering initiative work, or similar. Story points allow us to rapidly—and relatively accurately—estimate the size of work so that we can forecast sprints and releases with appropriate confidence.

How many jellybeans are in the left jar? How about the right jar? How confident are you in your estimate? I’m guessing 250 and 500 respectively, but I’m really not sure.

Now, relative to this left jar, how many jellybeans are in the right jar? Double. We got that almost instantly. I’m sure that’s pretty close, too.

How long would it take you to eat all of the jelly beans in the left jar? How long do you think it would take me? Can we agree that it’d probably take both of us twice as long to eat all of the jelly beans in the right jar?

There’s a couple of ways of facilitating team-estimates of story points, such as planning poker or “affinity estimating.” But the core concept remains the same. Choose one of your least complex, most certain, lowest-effort items as your “reference” story. This becomes a “1.” Using complexity, uncertainty, and effort as our criteria—you can use the mnemonic C U E—collaboratively size all stories using previously-sized stories as a reference.

Now that we’ve got your first “1,” everything else is a multiple of that. A user story that is similar in complexity, uncertainty, and effort is a 1 as well. Something that is twice the CUE is a 2, thrice a 3, etc. There’s a bit of a catch here that seems odd at first but makes more sense with practice. Rather than size stories 1, 2, 3, 4, et cetera, we use a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 80, 100. Many teams find it helpful to add 0 and/or ½ to allow for smaller tasks, and infinity for stories that are too large or vague in their current state to estimate.

Why do we use a Fibonacci sequence instead of allowing any number? We do this to help prevent the team from arguing about two close estimates when there likely isn’t enough available information to meaningfully choose one over the other. For instance, the difference between 12 and 13 is less than 10% which is well within our margin of error, but the difference between 8 and 13 is over 60%, which is significant.

Why do we use a modified Fibonacci sequence: 20 instead of 21, 40 instead of 34, 100 instead of 55? Two reasons. First, it helps increase the distance between the estimates. Second, the numbers are easier to add mentally. If your team would prefer the original Fibonacci sequence, go for it.

Eventually, your team will seemingly size stories almost by “feel.” A team member will say, “If that’s a 5, this is a 5. This one is less effort, but there’s more uncertainty.”

Notice that I am referring to these as “team estimates.” What this means is that the whole team should weigh in on the estimate, not just the people who expect to do the work. Even if someone doesn’t know much about a story’s because they have not worked on the technology before, they should still venture a guess and learn from their colleagues. It may be that this “naïve” developer knows something the others don’t! 

Because we are measuring the complexity, uncertainty, and total effort—which remain the same regardless of who is doing the work—rather than the time it takes for a given group of developers to complete the story (which does not), we can come to an agreement on points for every story. 

Another advantage of estimating as a team is that it helps ensure that we have incorporated the full wisdom of the entire team and have gained shared understanding. Let’s suppose Pat thinks the rest of the story is a “3” and the rest of the team thinks it’s a “13.” Is this because Pat is ignorant of the complexity, uncertainty, and/or effort and can learn something from the team, or is it because Pat knows a shortcut or trick that the team doesn’t? Either way, there’s learning to be had and these couple of minutes sharing insights with one another is time well spent.

Why shouldn’t we use absolute estimates like days or hours?

The whole concept of story points came from a RAND Corporation study in the 1940’s where they came up with the idea of the “Delphi Technique.” This technique is a lot like the Planning Poker technique we use today. And what they found is that relative estimates like Story Points are faster to generate, more accurate, and more flexible than time-based estimates such as hours, days, or weeks. 

Ok, now you’ve got an overview of story points. Learn about Planning Poker and Affinity Estimating next and have fun!