A Guide to Using the Fibonacci Sequence in Scrum

Reviewed by: Madhur Kathuria

Although you may see it commonly used, the Fibonacci sequence on a scrum team—or on any agile team, for that matter—is a completely optional way to describe the scope of work in terms of estimated numerical points. This series of numbers can help the scrum team "size" a product backlog item (PBI). Sizing items is how the developers on the team get a shared understanding of the work.

What Is the Fibonacci Sequence?

It's a sequence of numbers:

• 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on, and so on.

Any number in the sequence is the sum of the two that came immediately before it. So 5 is the sum of 3 + 2, 21 is the sum of 13 + 8, and so forth.

The sequence is remarkable because the ratio, shapes, and arrangements formed by Fibonacci numbers appear throughout the natural world, including the growth patterns of plants, the arrangement of leaves, the sections of your fingers, and the spiral shapes of seashells.

But that's not why it's used by agile teams.

Benefits of Using the (Optional) Fibonacci Sequence

Scrum teams can use Fibonacci numbers to understand the scope and size of their product backlog items. "Size" is not a simple estimate of how long a task will take. Instead, it's a shared idea of:

• Scope
• Complexity

Most agile teams do not estimate size based on time, i.e., they do not say a product backlog item sized as a one will take one day to complete. Time is not typically a useful metric for estimating the complexity and scope of a particular work item because a more senior team member may complete a PBI much faster than a junior team member. A size estimation should provide both team members with a shared idea of the complexity and scope of the work, not individual time estimates.

As the developers on the scrum team discuss which items to bring into the sprint, they may talk about and compare the sizes of different PBIs to get an idea of what to expect. For example, are they taking on too much complexity in the sprint? If one PBI involves a lot of complexity, would it be more manageable if it were broken up into smaller items?

This all raises the question, how do you describe the relative sizes between product backlog items? Enter, Fibonacci numbers. One sizing option among many.

How to Use This Size Estimation Scale

To use the Fibonacci sequence in scrum, most teams do a round-robin or all-at-once assignment of a number. By holding up a number of fingers or a card with a number on it, an individual expresses which Fibonacci number corresponds with the scope of the work item.

This may look like:

• Riley believes the PBI is a 3
• Leo thinks it's a 2
• Meera thinks it's an 8

Which of them is correct? The truth is that there's no single right answer. The ultimate score for the PBI is not a secret that the team must guess. Instead, these numbers are important because of the conversation they may spur and the process of agreeing on the scope of the work by the people who will be doing it.

What's most important is the relative size of each number to the other, not the number itself. Think of it this way: Meera thinks the PBI is an 8, which is quite a bit larger than the 2 or 3 proposed by her colleagues. 

One thing to note is that, in the pattern, the next number is 50 or 75% greater than the previous number. So if Leo thinks it's 2 and Riley thinks it's 3, Riley's estimate is that the item is 50% bigger than what Leo thinks. This little comparison helps the team identify the relationship between different backlog items.

No one is wrong, but Meera may see complexity and scope that her teammates haven't yet recognized. Now's the perfect opportunity for her to discuss what she sees so they can synchronize and plan their work activities to account for it.

On the other hand, Riley and Leo may have foreseen the complexity but know about a new company process that will simplify the work. They can discuss it with Meera, who may ultimately change her number to a 2 or 3.

In both cases, there was never a wrong or right number. The benefit of sizing with Fibonacci numbers is how it supports collaboration, clarity, understanding, and the team's ability to plan their work for the sprint.

Using a Shorter Section of the Fibonacci Sequence

An extensive sequence of numbers may ultimately be too many to choose from. To simplify sizing, some agile teams use a shortened version:

• 1, 2, 3, 5, 8, 13, 21

Numbers on the left are generally smaller scope, less complex values. Numbers in the right may be used by the team to indicate large scope and complexity. For the latter, the scrum team may decide to remove some of the work from that PBI and move it to another item to be worked on in a future sprint.

How Fibonacci Numbers Support the Team

Not only do these values let a scrum team know when they may need to break apart a product backlog item, but they may also be used in sprint planning to:

• Plan realistically for team absences. If the teammates believe they can complete a greater sum this sprint than they have historically, but they also have two people who will be out on vacation, they may use this information to reshuffle PBIs for the sprint, perhaps moving some PBIs to the backlog for consideration in a future sprint.

• Cultivate a sustainable pace. These numbers can help scrum masters, product owners, and developers on the team prevent burnout. Each sprint will have a sum from the combination of these numbers, which you can call points. Sprint 1 may have added up to 65 points, sprint 2 was 50 points, and now at the beginning of sprint 3, the team is considering 100 points. That's a big jump in scope and complexity planned for sprint 3. One hundred points may be necessary for sprint 3, and perhaps the team is prepared for it. But if the team finds themselves continually climbing higher and higher sprint after sprint, they may be headed for burnout. The points determined by the Fibonacci numbers can help the team see this pattern and discuss what it means for sustainable pacing.

• Provide evidence for retrospective topics. Did the scrum teammates complete a much higher or lower number than their trend? Why or why not? Were tools, processes, interactions, or team members added or removed that may have contributed? Is the team finding that their Fibonacci number assignments are ultimately way too low for the effort of the tasks? That's just a couple of examples of the many ways these sizing estimates may spur discussion in the sprint retrospective. 

Fibonacci Numbers to Understand Velocity 

A scrum team's velocity is a measurement of how many points they complete in a sprint. Points are whatever metric they use to size a product backlog item. So a team's points may be the Fibonacci numbers. A team may regularly complete between 60-75 points per sprint, as an example.

Over time, the team can see their velocity trend. The velocity will go up and down over time, but they can see averages and typical points-completed-per-sprint. The velocity is the sum average of the last few sprints, not a number that the team commits to completing ahead of a sprint or adds up before a sprint. 

Scrum teams do not use velocity to prove performance to management but instead as an internal metric to help them plan their work, make commitments and forecasts, and identify if processes, tools, interactions, or any other factors may be influencing changes in their velocity.

Alternatives to Fibonacci Estimation in Scrum

These numbers are just one of many ways an agile team can size their work items. Other options include:

• A doubling sequence, such as 2, 4, 8, 16, 32
• T-shirt sizing, such as XS, S, M, L, XL
• A planetary scale, such as Earth, Saturn, Pluto
• No estimates at all—sizing should be used if it helps your team, and some scrum teams take a no-sizing approach

More important than the actual type of sizing measurement used is your team's shared understanding of the relative size between each measurement. Gaining experience as a team so you have the same idea of how a 13 is different from an eight and a 21 is the path to understanding the scope of your shared work and how to plan accordingly.

Subscribe for More Agile Tips and Ideas

Scrum Alliance's Resource Library is full of informative articles about working on a scrum team and expanding your agile skill set. Please subscribe to our emails to receive new articles directly to your inbox.