Agile estimation: Using the Fibonacci sequence for story points

My first contact with Fibonacci happened when a programming professor asked me to create an algorithm to calculate the Fibonacci sequence. At the time, I had no idea what to do.

Fibonacci is a numerical sequence that goes to infinity. It starts with 0, followed by 1. The rule is simple: the following number is the sum of the previous two numbers. Hence, the sequence is 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, and so on.

You may wonder what Fibonacci has to do with agile? The most common estimation method is story points, a technique based on the Fibonacci sequence.

In this article, we’ll explain how Fibonacci works with agile, describe some pitfalls to avoid, and list alternative estimation methods.

Fibonacci and story points

If you work with scrum, kanban, scrumban, or any other agile framework, you’ve probably heard the term story points before. Most teams estimate their work with story points.

Unlike classic project management, agile teams strive to estimate complexity because the effort differs depending on who works on it. That’s where Fibonacci comes in handy.

When I worked with classic project management, we estimated tasks in hours. Our scale used multiples of four hours. For example, a task could last four hours, while another might last 16 hours, another for 20 hours, and so on.

This is a waste, and this estimation format is purely based on the effort required to complete a task. We rarely found ourselves correct and spent valuable time talking about improving our estimates, while distracting ourselves from getting the work done.

Story Points are different.

Imagine you want to run a half marathon. The complexity of the task is high, but the effort varies across individuals. For example, I’d take a lot of time to prepare for it, whereas my dad ,  an experienced runner , would just wake up on the day of the race and run.

Understanding story points

Now, let’s understand why estimating complexity is more efficient than estimating time.

Complexity can be understood the same way by everyone in the team, while time cannot. Story point estimation aims to build a shared understanding of the complexity behind getting a job done.

As I mentioned before, complexity doesn’t grow on a linear scale. The more complex something gets, the more uncertainty we face. That’s where Fibonacci is useful.

Now comes a tricky bit. Story Points don’t follow the Fibonacci sequence strictly. Because of this, it requires some adaptations:

• Fibonacci — 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, etc
• Story Points — 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

It’s not black and white. Some teams will use the classic Fibonacci sequence, while others will use the adapted one. In practice, it doesn’t matter because both lead to the same result.

The idea is that the bigger the number, the less you know. As a product leader, whenever I see an estimate higher than 13, I understand the team lacks clarity and needs to work on understanding the problem space more. Larger numbers show me that I need to break the work into smaller pieces to aid progress.

How to use the Fibonacci sequence for story point estimation

People often ask me, “How do you move from estimating in time to estimating in complexity?

A simple way to start using Fibonacci and story points is:

1. Chose the scale, classic Fibonacci or story points
2. Consider around 10 tasks you’ve done recently
3. Pick a task you consider medium complexity and give it a 5
4. Pick other tasks and compare them with the previous ones. If more complex, you can give an 8 or 13. If simpler, a 3 or 2
5. Rinse and repeat — keep doing this exercise of comparing and adjusting

After that, the team is ready to start using story points. The goal isn’t to achieve perfection, but to keep progressing and learning by doing. It’s fine to re-estimate. The team’s understanding will evolve over time.

After the team has an initial understanding of complexity from previous work, it’s time to run an estimation session using the chosen scale. Here are some tips for that:

• Don’t get stuck on details. Compare the task estimated with previous ones and ask, “Is it more complex or less complex?” Then estimate accordingly
• Focus on building a shared understanding of complexity instead of implementation efforts
• Don’t be afraid of giving a “wrong” number. Be afraid of getting stuck in abstract discussions

The beauty of Fibonacci is its applicability. When done right, teams become more pragmatic and focused on getting hands-on faster. They are inclined to embrace the unknown because they accept not having all the answers upfront.

Common mistakes

Not everything is sunshine and rainbows in the Fibonacci sequence. Teams often get trapped, and estimation quickly becomes pointless. I’ve fallen into some traps, and imagine you’ll face them too.

Let me share the most common mistakes with the Fibonacci sequence:

• Conversion to time — It’s a brutal mistake to convert the Fibonacci sequence to hours. For example, every story point equals an hour. This will make your team estimate in hours and ignore complexity
• Lack of shared understanding — Team members come and go. Yet, new ones are barely onboarded on the team’s understanding of complexity. Other team members start viewing the world from different lenses.
• Mechanical estimates — Some software engineers hate estimating because it’s too abstract for them. Therefore, they just give an estimate to move on, and the team ignores the most critical part of estimation
• Horizontal boundaries — Often, team members push for splitting tasks into technical aspects (e.g., frontend and back-end). Agile is about collaboration, and the team is supposed to solve problems together
• Transfer tasks — Teams have different perceptions of complexity. For example, what one team perceives as a complexity 5, the other may see a 3. That’s why estimates aren’t transferable across teams

When you fall into these traps, estimation loses value and teams don’t care about them anymore. It’s fundamental to address this situation.

Alternatives to the Fibonacci sequence

Although story points is the most-used estimation method worldwide, there are other options. You can use whatever floats your boat.

Below are some alternatives to Fibonacci story point estimation:

T-shirt size

Define ranges of time per item. For example, small could be 1–2 days, while medium could be 2–4 days. There’s flexibility in how you define the ranges and their evolution. This is generally a good alternative to estimating epics in sprints

Absolute time

You can estimate in time if you want, though I’d discourage it. The reason is simple. We’re generally bad at absolute estimates because they create false expectations. The result is often horrible, and it distracts the team

#Noestimates

Not estimating tasks is becoming a trend now. Many teams realize that estimation itself doesn’t help get the work done. That’s why they stop estimating their tasks. It’s a simple method. You pick a task, talk about it, refine it, and then ask, “Does it fit our cycle (Sprint)?” If it doesn’t, the team breaks it down until it fits

Conclusion

As a final thought, avoid focusing on predictability. Instead, focus on creating enough understanding to enable progress.