Story Points Explained

What are story points?

Story points can be described as:

• Team-specific units of relative size used in estimating requirements.

• A unitless measure of magnitude for work yet to be done, based on relative sizing.

• Something that enables estimation without trying to determine how long a task will take.

Tip: Story points measure effort, not complexity. 

Why using story points matters

You should use story points because:

• They predict completion.

• Accuracy and precision are not the same thing. Precision is a lot more expensive. Precision is always desired, but accuracy creates more value. However, story points provide sufficient accuracy when working in nondeterministic systems.

• Time has no direct relationship to progress, but the rate of effort resolution will forecast completion.

• Velocity stabilizes story point estimates, so you get more predictability, which is the ultimate goal of creating estimates.

Tip: Because we work with fixed-length sprints, it is not critical to understand how long a user story takes but rather how many story points fit inside a sprint.

How to use story points

Using story points is rather simple; all you need to do is compare two things (in our case, user stories vs. tasks; tasks vs. improvements, etc.) and then size them.

Let's take a look at an example:

I really can't tell how long it will take me to make a trip from Porto to Vila Real, Viseu, Lisboa, or Faro. But if I say that the distance between Porto and Vila Real is 1, then the following statements are true:

• Porto to Viseu is 1.

• Porto to Lisboa is 3.

• Porto to Faro is 5.

How long does it take? I really can't say, but I can say that the route to Lisboa is roughly three times longer than the route to Vila Real. I can also say that the route to Vila Real and Viseu are roughly the same. I'm pretty sure that the route from Porto to Faro is roughly five times longer than the route to Vila Real. And I can also venture to say that the route to Chaves looks roughly twice as long as the routes to Vila Real and Viseu.

As you can see in this example, our frame of reference is the route between Porto and Vila Real. We made it our "1" story point. If I replicate this exact exercise and substitute time, I really wouldn't know how to start. I'd ask myself how long a trip from Porto to Vila Real takes. One hour? One hour and a half? How is the traffic? How is the weather? Who's going to be the driver? How is the road surface?

To derive an estimate, you need to consider multiple variables, thus making it (almost) impossible to give a precise estimate. Because time-based estimates are quite precise, we would rather use story points, which are not precise but accurate (enough) for us to use them and to give enough value to the estimates.

To that end, the first step for any team is to decide what a user story of 1 point looks like. As soon as you have your reference user story, and if the reference is 1 point, then does the next user story look the same? Bigger?

If it's about the same, then you give it a 1. If it looks bigger, then you need to decide if it is twice as big (2 story points), three times bigger (3 story points), and so on.

As soon as you know the reference story and its point value, you will have all your subsequent user stories properly estimated in a much faster way than using time-based estimates.

Tip: It's all about accuracy, not precision. We would rather be roughly right than precisely wrong.

Relationship between time and points

The relationship between time and points depends on the team. Points measure effort, not time, so you don't have a universal relationship between time and points. It's only when you analyze the historical data that you can relate time with points in one of the following ways:

1. Assign the hours to the user stories subtasks.

2. Estimate the time that it takes the team to complete a user story.

You will find that one story point can take from X to Y number of hours. Story points can't be related with a specific duration (e.g., two hours) but rather with a duration interval (e.g., two hours to eight hours).

It's perfectly natural that, during the execution of several sprints, a team can deliver more story points per sprint, thereby reducing the amount of time that each user story takes to complete. The team becomes faster. Unfortunately, some teams also get slower with time. This is typically due to technical debt, which leads to an increase in the amount of time that a user story takes to be completed.

For more agile tips, go here.