One of the first things used to describe story points is a negative: story points do not equal time. 1 story point can not be equated with 1 hour, 3 hours, or any other unit of time. While it can be advantageous to have a unit of work that isn’t associated with time, it is important to note that story points will ultimately be a unit of time.

Story points are used in conjunction with sprints. The number of story points completed in a sprint is the sprint velocity. But a sprint is a unit of time. It doesn’t matter if that unit is 1 week or 1 month, it is still a unit of time. To say that we can have a sprint velocity that uses story points, but that story points aren’t related to time, would break the transitive property. It makes no logical sense.

Yet, it is still important to treat story points as if they don’t equal hours. There are a number of reasons for this.

For the first, I’ll ask the question: What would you think of first if I told you to think of an animal without thinking of elephants?

Probably elephants!

So what would a developer think if you asked them to calculate the amount of work required by a task, but to not worry about finishing it by the end of a sprint or a release date?

They would worry about finishing it in time!

Software projects are often on tight timetables. There is pressure to deliver quickly. However, it is important to understand all options available, even the time consuming ones, when planning out a project. Knowing about these options can create discussions about how important certain things are. Knowing that the most preferable option for a task that is more important than other tasks will open up conversations about other tasks getting cut.

If you were worried about finishing something on time though, would you try to think of things that would exacerbate that worry?

Probably not! That would be crazy. We didn’t evolve with such terrible survival instincts.

Worrying about finishing a task on time can limit a developer’s ability (or willingness) to bring up more time consuming options. Story points abstract units of time to help prevent people from worrying about finishing a task in a period of time. With that worry gone, the conversation is focused solely on the complexity of a task and the options available.

There are some other advantages as well. Not all developers work at the same speed on the same tasks. Even when you ignore the differences between junior and senior developers, most developers go into some kind of specialty. There’s front end, back end, AI, 2d graphics, 3d graphics, etc. Then there are the different sub-systems at any sizeable company. It is unlikely that all developers have equal experience and familiarity with all of those sub-systems.

The hours required for one task may take Developer A 2 hours and Developer B 4 hours. The hours required for another task could result in 4 hours for Developer A and 2 hours for Developer B. Story points help normalize the estimate of a task by creating a consistent metric for a task independent of the person working on it.

I’m not of the opinion that story points are right for every team. However, it is important to understand the nature of story points in order to use them properly and whether they are even appropriate for a given team. Teams that suffer from the problems story points tackle can benefit greatly from using them. Teams should not use story points just because they read that they should.