Fibonacci story points: A practical guide to agile estimation – Beragampengetahuan

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.

What is the Fibonacci scale?

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.

How does the Fibonacci scale apply to agile estimation?

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.

Why is the Fibonacci scale important for agile estimation?

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.

---

---

Fibonacci story points

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:

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

Regardless of the exact numbers used, the principle of Fibonacci’s scale applies.

Using Fibonacci story points in agile estimation

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:

1. Determine a common understanding of story points

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:

• If it’s more complex then give it a higher story point (e.g. 8 or 13)
• If it’s less complex then give it a lover story point (e.g. 2 or 3)

Keep doing this exercise of comparing and adjusting through all the sample tasks until all tasks are given a story point.

2. Estimate all work items the team will work on

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:

• 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
• If the discussion gets involved then either the work item is more complex or there isn’t a shared understanding of how you approach story points
• 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, you become more pragmatic and focused on getting hands-on faster.

3. Plan your development using Fibonacci story points

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:

 

Benefits of using Fibonacci story points

When it comes to using Fibonacci story points, the biggest benefits include:

• It can involve the whole team in its application
• It allows a framework for estimating
• It’s easy to implement, with limited investment of time
• It provides a method of monitoring development activity
• It can help identify learning opportunities

Mistakes when using Fibonacci story points

The reality is that no framework is perfect and there are some potential issues that can arise when using Fibonacci story points:

• Converting story points to a time equivalent — Story points represent complexity and not time so you can’t assign time to it; for example, every story point equals an hour
• Anchoring bias — There’s a tendency when discussing in groups that if one person starts at a particular reference point then others will adjust their own view from that point (i.e., it has anchored them). This can lead to individuals adversely influencing the group
• Lack of shared understanding — Over time teams change and without appropriate onboarding, new team members may come with a different frame of reference for story points. This can result in variations in estimations and inconsistency over time
• 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
• 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

How to improve your use of the Fibonacci scale

Once you’ve started using the Fibonacci story points approach, try these techniques to improve it within your team.

Encouraging more discussion

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?

Monitoring your velocity

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.

Reviewing your story point references

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?

Alternative estimation techniques to the Fibonacci scale

The Fibonacci scale isn’t the only approach to providing estimation in agile development, there are other options available, including:

 

 

T-shirt sizes

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:

• Small 1–2 days development
• Medium 3-5 days
• Large 5-10 days
• Extra large 10-20 days

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.

Absolute time

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.

#Noestimates

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.

Fibonacci story points FAQs

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.

Is 5 story points a week’s work?

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.

How many story points are there in a day?

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.

How many story points should the team complete in a sprint?

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.

How do you use story points in Jira?

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.

Can we change the reference point for story points?

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.

Do all tasks need to be estimated with story points?

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.

Embracing Fibonacci story points for agile success

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.

beragampengetahuan generates product insights that lead to meaningful action

beragampengetahuan 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 beragampengetahuan, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. beragampengetahuan 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 beragampengetahuan today.