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.
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.
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:
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.
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:
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:
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.
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:
When you fall into these traps, estimation loses value and teams don’t care about them anymore. It’s fundamental to address this situation.
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:
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
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
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
As a final thought, avoid focusing on predictability. Instead, focus on creating enough understanding to enable progress.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A marketing plan is a structured guide for a company’s marketing activities across a specific period.
Alan Fliegelman shares how his work at DHI is transforming the job search process and the various transitions he’s seen in his time there.
Loss aversion is the psychological concept behind the human response that attributes more to losses versus gains.