Editor’s note: This blog was updated 17 January 2025 by Robert Drury to provide how context around how to apply Fibonacci story points to agile estimation, including a new FAQ section, how to improve your use of Fibonacci, and why it’s important.
Fibonacci was an Italian mathematician from Pisa, considered to be “the most talented Western mathematician of the Middle Ages” and his impact on how we approach mathematical problems continues to be used today.
However, you may wonder what Fibonacci has to do with agile estimation. The answer lies in the use of story points.
This article covers the Fibonacci scale, how it works with agile estimation, some pitfalls to avoid when using it, and alternative estimation methods.
Fibonacci determined a numerical sequence that works on the basis of a number being the sum of the previous two numbers in the sequence. Starting at zero this gives us the following: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.
This simple sequence can be found in many aspects of nature and provides mathematicians, designers, software development teams, and others with the opportunity to develop accurate approaches to mathematical problems.
Due to its gradual increasing and widening nature, the Fibonacci scale is used to determine the perceived complexity of work by mapping the scale to story points.
When estimating work, you can then apply a Fibonacci story point to each story and then track the number they complete during a period of development.
Fibonacci story points work under the theory that the less complex a piece of work is the more likely you are to accurately estimate the scale of the work. On the other hand, the more complex a piece of work becomes the less likely you are to accurately estimate the scale of work and so the story points become gradually larger and spaced out to account for this.
For example, teams find it easier to recognize the difference in complexity of smaller, more known work items, allowing them to determine the difference between a work item estimated at 1 story point and a work item estimated at 2 story points.
However, when the work becomes more complex and more unknowns are present it becomes difficult to tell whether a work item is 1 or 2 story points different from another, so the gradual gaps between numbers in the Fibonacci scale provide a method for handling this uncertainty.
Strictly speaking, story points for agile estimation may not follow the exact Fibonacci scale. In some instances you can round them for simplicity, giving you the following:
Regardless of the exact numbers used, the principle of Fibonacci’s scale applies.
Due to the nature of different products and how they function, it’s necessary for you to determine a common understanding of the scale. No two development teams have an identical application of Fibonacci story points. To get started, follow these steps:
The first thing you need to do is choose whether you want to use the classic Fibonacci scale or Fibonacci story points. Once you do this, determine approximately 10 recently completed tasks for reference. From these pick one that you perceive as medium complexity.
The medium task is 5 and works as your starting point to assign the rest of the numbers. Take the next task and compare it with the original reference:
Keep doing this exercise of comparing and adjusting through all the sample tasks until all tasks are given a story point.
After you determine a common understanding, you’re ready to start using story points as part of your agile development process.
The goal isn’t to achieve perfection, but to keep progressing and learning by doing. It’s fine to re-estimate. Your understanding will evolve over time.
When running an estimation session there are a few general rules to help it run smoothly:
The beauty of Fibonacci is its applicability. When done right, you become more pragmatic and focused on getting hands-on faster.
Once your backlog of work items has been estimated then you can start to use the story points to plan your development by estimating which work items you can complete within your defined development period.
If you work in two week development periods (called sprints in agile development) you can estimate that you’ll work through a series of work items. The total story points for your selected work item will be your expected velocity of work.
For example, you might select ten work items for completion during the two week period, with Fibonacci story points of 1,1, 2, 2, 3, 3, 5, 5, 8, 13, giving you an expected sprint velocity of 43:
When it comes to using Fibonacci story points, the biggest benefits include:
The reality is that no framework is perfect and there are some potential issues that can arise when using Fibonacci story points:
Once you’ve started using the Fibonacci story points approach, try these techniques to improve it within your team.
When starting out with Fibonacci story points, teams often simply estimate the score and move on, however, more advanced teams use simultaneous scoring (where all team members show their estimates at the same time) to provoke discussion about the work item.
For example, a team of five people review a work item and simultaneously estimate the following story points; 3, 3, 3, 3, 13. This implies that one team member either a) doesn’t share the same reference point as the other four members, or b) they know more about the complexity of the work being proposed that the other four members don’t.
Either way, this is an opportunity for a group discussion into the variance being seen. Why does the fifth person think it’s more complex? Is this understanding correct? How can we reach a common story point estimate?
At the end of your development period it becomes possible to review the story points the team actually completed which can then be used to feed back into the planning for your next development period.
If you completed all 43+ story points then for the next development period you can allow for a greater number of story points to be delivered. If you completed fewer than 43 points then you can adjust your work items downwards.
Your velocity can be tracked over time to assess performance and identify if any issues have arisen that have slowed you down or areas of improvement that could speed you up.
Over time, the team changes and the work the team is doing changes, so there are opportunities to review the references you use to determine Fibonacci story points.
Does something that was estimated as 5 story points six months ago still look like 5 story points now, or has something changed?
Do you need to adjust how story points are estimated or is the work actually getting more or less complex?
The Fibonacci scale isn’t the only approach to providing estimation in agile development, there are other options available, including:
T-shirt sizing works on the principle of determining a reference framework for the size of work and applying a t-shirt size to it. For example:
Each work item is then assigned a t-shirt size and teams can then plan their work based upon it. This is a quick and easy approach to getting an outline estimate, although it doesn’t provide the flexibility of accuracy of the Fibonacci scale approach.
As you’d expect, estimating absolute time means simply determining how long it takes to complete a task. Prior to agile development this was the most popular approach, however, people tend to struggle with absolute estimates and they create false expectations.
The definition of an estimate is “a rough calculation of the value, number, quantity, or extent of something.” But how does providing the estimate actually help get the work done? Rather than spend time estimating something, why not just stop estimating tasks and just get on with the work.
If you’re still deciding whether to adopt Fibonacci story points, review these FAQs to determine if it’s a good fit for your product team.
No. Story points do not equate to time. They relate to the complexity of a task and are determined differently in every development team. These aren’t constant across all development teams.
Story points do not equate to time. They relate to work done by a specific team and are not a constant across all development teams.
The velocity of a team will vary from team to team for a variety of reasons, from the different methods of determining story points and the length of a sprint, to the differences in product complexity and handling ongoing bugs. A specific team can determine how many points they can handle, but this will vary from other teams, even in the same organization.
Within Jira you can set the estimation measurement to be in either time or story points. This allows you to add estimation fields within a Jira Issue that can then be completed and tracked using the in-built reporting to determine a team’s velocity.
Story point determination should be reviewed to maintain its relevance to the work being done. You can change reference points if you identify patterns in the type of work being done, however, any change will have an impact on velocity reporting as the method of determining this will have changed.
All planned tasks should be estimated to ensure that teams can benefit from the planning and tracking aspects of story points. Typically bugs (errors in previously released code) aren’t estimated as the focus is usually on fixing these rather than working out how long it will take to fix them.
When applied to Agile estimation the Fibonacci scale can be a powerful tool for development teams to plan for success.
From its approach of encouraging team participation and group knowledge, to its ability to handle tasks from small to large, Fibonacci story points provide teams with the opportunity to try and bring more certainty into a world of uncertainty.
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.
Randolph D’Souza talks about how he works to align different teams together, such as product, OEM engineering, and sales.
Understanding the root causes of project bloat is essential for aiming to improve productivity and streamline workflows.
Mahesh Guruswamy shares experiences learning from and coaching others on how to have tough conversations and how this inspired his book.
A prioritization matrix helps assist in determining what to work on next and quickly assess whether an initiative is worth the company’s time and budget​​.
Learn more →
