Story points - The most powerful aspect of a Scrum but also (unfortunately) the most misunderstood and underutilized aspect of Scrum.

What are Story points?

In Scrum, story points are a relative unit of measure used to estimate the effort required to complete a user story. They don't directly translate to actual time (hours or days). Story points consider the complexity, uncertainty, and amount of work involved in a user story, not just the time it might take.?

Story points are a relative measure. For instance: An user story assigned with 5 story points is considered to be about twice the effort of an user story assigned with 2 story points.

Estimating story points is a collaborative process where the entire scrum team discusses the user story and reaches a consensus on the effort involved. This is done as part of a product backlog review/estimation meeting that happens on regular cadence.

The Problem

A prevalent misconception exists where teams conflate story points with absolute time. This manifests in practices such as mapping 1 story point to half a day or 4 hours, 2 story points to 1 day or 8 hours, etc. OR mapping 1 story point to 8 hours, 2 story points to 16 hours, etc.

Equating story points to hours defeats the primary reason to use story points.?

What one team member might complete in a day might take another longer. Absolute estimates based on individual times can lead to siloed work and less communication. Story points provide a more abstract measure of effort that considers the team as a whole. Story point estimation encourages discussion and collaboration as the team assigns points based on shared understanding of complexity and effort.

Why mapping story points to absolute time is a problem

(Below explanation is an extract from the article written by Mike Cohn)

Let’s look at an example. For simplicity, let’s assume the scrum team has two members:

• Person A is a Senior Developer
• Person B is a Junior Developer

Person A is more experienced, skilled, and knowledgeable than person B. This leads to person A being four times more productive than person B. Any task that person B can complete in four hours, person A can complete in one hour.

This team of 2 has an average velocity of 25 story points per sprint. This leads to them planning to complete the following 4 product backlog items in the coming sprint. ?

Because person A is four times more productive than person B, person A will be able to complete four times as many points in the sprint. That means person A will complete 20 and person B will complete 5 of the 25 points planned in the sprint.

Person B can work on any of the five-point items and successfully complete it during the sprint. Let’s assume person B chooses User Story 4. That leaves person A with user stories 1, 2, 3 as shown below.

So what do we tell someone who asks, “How many hours does it take to complete one point?”

If we assume this example is a 1-week, 40-hour sprint, there are 3 possible answers.

• Person A worked 40 hours and delivered 20 points. Therefore, one point takes two hours of work.
• Person B worked 40 hours and delivered 5 points. Therefore 1 point takes 8 hours. Note that person B’s number of hours per point is 4 times that of person A. This corresponds to the initial assumption that person A is 4 times as productive.
• Together, they worked 80 hours and completed 25 points. Therefore, 1 point takes 3.2 hours (80/25).

You can see from this example that there is no equivalence between points and hours. You cannot say one point equals such-and-such number of hours. For person A, a point is 2 hours, for person B it’s 8 hours, and for the team it is 3.2 hours.?

So in conclusion, by not mapping story points to absolute time, every developer in the scrum team can discuss and estimate the user story together, and the estimate will be accurate no matter which developer works on the story. In this way, story points are still about effort, but the amount of time it takes to complete each point is not fixed at the same amount for all team members.