How to Implement Story Points in a Team?

Many of you have asked me to explain how to implement story points in a team, so I’m writing this article to address your questions on the subject.

What is an Story Point?

An story point for a user story (or technical task) includes various factors that developers need to consider for estimation:

• The effort required to develop the feature.
• The complexity of the task.
• Potential risks that might arise during development.
• Any unknowns present during estimation.
• Possible dependencies on external elements.

It’s important to note that an story point is an abstract concept and cannot be equated to man-days. However, it does contribute to predictability.

Yes, effort points do have a time component, contrary to some claims. But their estimation is not solely based on time, and one story point doesn’t necessarily equal one day.

The Fibonacci Sequence

Agile teams often use the Fibonacci sequence to represent these estimations.

The Fibonacci sequence goes: 1, 2, 3, 5, 8, 13… Usually, teams stop at 13, but some also include 21.

“Higher estimates are less precise.”

This is why the Fibonacci sequence aligns well with this concept.

In Agile, differentiating between 12, 13, or 14 isn’t very meaningful. High estimates in software development can’t be as precise because there are too many variables. So, we use 13 to represent an estimation within this range.

How Can the Team Define Story Points?

It’s essential to understand that each team will have its own reference for story points. Comparing effort points between two teams doesn’t make sense.

1. Initial Estimation

During the first estimation session, the team should consider the factors mentioned above. It’s not easy for teams during their first attempt, especially if they’ve never done this before. It’s helpful to have a poster in the room reminding team members of these considerations.

2. Initial Estimation Reference

During the initial estimations, teams can define “reference” tasks to create a starting point for their story point scale. For instance, when a task is estimated as “1”, it becomes the reference for an estimation of 1. The same is done for an estimation of 13.

This reference can be valuable for teams new to Agile estimation. In such cases, the reference should be prominently displayed in the team’s visual management.

3. Estimations Will Evolve Over Time

Story point estimations will evolve over time and won’t remain the same. This is acceptable because, when predictability is required, only the last three sprints are considered.

Several main reasons lead to changes in team estimations:

• The team gains a better understanding of its environment.
• The team becomes more familiar with the context.
• The arrival or departure of team members can affect estimations.

Managers or product owners should never pressure development teams into assigning specific story points. The predictability remains intact even if the reference evolves over time.

A Simple Example to Understand Estimations

Here’s a helpful example to understand how story points work:

I present different types of vehicles and ask the team to estimate their story points for building these vehicles. They are required to consider essential factors: difficulty, development effort, uncertainty, risk, and dependencies.

I introduce the first vehicle: “a 300-horsepower sports car” and ask them to assign an story point between 1 and 13. I don’t reveal the other vehicles.

The team will discuss the possibility of a scooter or even a rocket. This helps them position the sports car within their story point range.

Unknowingly, the team creates its reference scale.

I repeat this process for each of the vehicles, introducing them one by one. Eventually, I propose making the scooter the lower reference (usually estimated at 1) and the ferry the upper reference (usually estimated at 13).

The team then understands that they’ve created their own story point reference. I explain that the same principle applies to software development.

Interesting Special Cases

Estimation Impossible

In some cases, you may not be able to estimate a task. Here are a few possible scenarios:

• A need to research solutions.
• A bug with an unknown root cause.
• Data analysis (e.g., in big data projects).

In such situations, you can introduce a concept called “spike,” which represents a timeframe dedicated to investigating a problem or hypothesis. These tasks are not estimated.

Avoiding the Use of Complexity

Story points are not solely about estimating task complexity. Using the term “complexity” can lead teams to have a flawed perception of effort points.

Conclusion on Story Points

I hope this article sheds light on the practical aspects of implementing story point estimation in Agile teams. Feel free to ask for further clarification in the comments if you still have questions.