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.
It's a sequence of numbers:
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.
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:
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.
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:
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.
An extensive sequence of numbers may ultimately be too many to choose from. To simplify sizing, some agile teams use a shortened version:
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.
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:
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.
These numbers are just one of many ways an agile team can size their work items. Other options include:
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.
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.
Get the latest resources from Scrum Alliance delivered straight to your inboxSubscribe