Agile estimation: Using the Fibonacci sequence for story points

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.

Fibonacci and story points

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.

Understanding story points

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.
Over 200k developers and product managers use LogRocket to create better
digital experiences

Learn more →

Now comes a tricky bit. Story Points don’t follow the Fibonacci sequence
strictly. Because of this, it requires some adaptations:
o Fibonacci — 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, etc
o Story Points — 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100
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.

How to use the Fibonacci sequence for story point

estimation
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:

1. Chose the scale, classic Fibonacci or story points

2. Consider around 10 tasks you’ve done recently
3. Pick a task you consider medium complexity and give it a 5
4. Pick other tasks and compare them with the previous ones. If more
complex, you can give an 8 or 13. If simpler, a 3 or 2
5. Rinse and repeat — keep doing this exercise of comparing and
adjusting
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:

o 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
o Focus on building a shared understanding of complexity instead of
implementation efforts
o 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, 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.

Common mistakes
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:

o Conversion to time — It’s a brutal mistake to convert the

Fibonacci sequence to hours. For example, every story point equals an
hour. This will make your team estimate in hours and ignore
complexity
o Lack of shared understanding — Team members come and
go. Yet, new ones are barely onboarded on the team’s understanding of
complexity. Other team members start viewing the world from different
lenses.
o 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
o Horizontal boundaries — Often, team members push for
splitting tasks into technical aspects (e.g., frontend and back-end).
Agile is about collaboration, and the team is supposed to solve
problems together
o 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
When you fall into these traps, estimation loses value and teams don’t care
about them anymore. It’s fundamental to address this situation.

More great articles from LogRocket:

o How to implement issue management to improve your product

o 8 ways to reduce cycle time and build a better product
o What is a PERT chart and how to make one
o Discover how to use behavioral analytics to create a great product
experience
o Explore six tried and true product management frameworks you should
know
o Advisory boards aren’t just for executives. Join LogRocket’s Content
Advisory Board. You’ll help inform the type of content we create and
get access to exclusive meetups, social accreditation, and swag.
Alternatives to the Fibonacci sequence
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:

T-shirt size

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
Absolute time

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
#Noestimates

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

Conclusion
As a final thought, avoid focusing on predictability. Instead, focus on
creating enough understanding to enable progress.
 Using the Fibonacci
scale in Agile
estimation

Chances are that you’ve had the experience of being given

an estimate that turned out to be completely wrong—the car
wasn’t repaired in two days or the table at the restaurant
wasn’t ready in 15 minutes.

If estimates can be inaccurate, why are they important to

project planning?

It’s a matter of setting the right expectations and

determining how much work is realistic to complete in a
given timeframe—teams need to account for a project’s
complexity in order to decide the amount of effort required,
the number of resources needed, and ultimately, how much
time it will take to complete the project.

Many developers in Agile environments have successfully

improved the estimation process using the Fibonacci scale or
a modified Fibonacci sequence to estimate the work that
needs to be completed in an iteration.

Learn what the Fibonacci sequence is and how you can apply
it to Agile estimations.
What is the Fibonacci sequence?
Fibonacci was an Italian mathematician in the Middle Ages
who wrote a book called Liber Abaci (Book of Calculation).
This book introduced and popularized the Hindu-Arabic
numeral system in the Western world. In Liber Abaci,
Fibonacci also presented the following problem:

A certain man put a pair of rabbits in a place surrounded on

all sides by a wall. How many pairs of rabbits can be
produced from that pair in a year if it is supposed that every
month each pair begets a new pair which from the second
month on becomes productive?

To estimate the answer, Fibonacci introduced an exponential

sequence of numbers, now known as the Fibonacci number or
Fibonacci sequence. In the sequence, each number is the
sum of the preceding two numbers:

0, 1, 2, 3, 5, 8, 13, 21…

Why the Fibonacci series is used

in Agile
The Fibonacci sequence is found in many different disciplines
and in nature. For example, it has been used to describe
plant life growth, estimate population increases over a
specified timeframe, model virus breakouts, and predict the
behavior of financial markets.

But what does this long string of numbers have to do with

Agile planning?

Essentially, the Agile Fibonacci scale gives teams a more

realistic way to approach estimates using story points. Story
points are used to represent the size, complexity, and effort
needed for completing or implementing a user story. Each
story point is assigned a number from the Fibonacci scale.
The higher the number, the more complex the story point,
and presumably, the amount of effort it will take to complete.

As discussed previously, estimates can often be inaccurate—

and that happens because people tend to be overly
optimistic.

For example, instead of making an estimate based on a

similar project we completed in the past, we believe we can
get it done faster because we are more experienced and we
are sure that this time there won’t be any problems that
cause delays.

Because the Agile Fibonacci Scale is exponential rather than

linear, it helps teams to be more realistic when looking at
larger, more complex tasks.

To help you understand why the exponential nature of the

Fibonacci series is helpful, we’ll paraphrase an analogy used
by Mike Cohn, one of the founders of the Scrum Alliance:

Imagine holding a one-pound weight in one hand and a two-

pound weight in the other. Without looking, you are likely
able to determine which is which because the 2-pound weight
is noticeably heavier—the two-pound weight is 100% heavier
than the 1-pound weight).

If you were to hold a 20-pound weight and a 21-pound

weight, it is harder to determine which is heavier because the
difference between the weights is not that significant—the
21-pound weight is only 5% heavier.

Each number in the Fibonacci scale is exponentially larger (by

about 60%) than the previous number. Teams can more
easily recognize the differences and define the complexity of
each story point.

How to use the Fibonacci scale in

Agile
Many Agile teams use the planning poker technique for
estimating story points.

This technique involves card decks with Fibonacci numbers

starting with zero (0, 1, 2, 3, 5, 8, 13, 21, etc.) or a modified
version of the sequence (0, .05, 1, 2, 3, 5, 8, 13, 20, 40, 100).
Your team can use any number sequence with a fixed ratio
(e.g., 1, 2, 4, 8, etc.) as long as the team understands and
agrees with what the ratios mean.

Each member of the estimation team, aside from the

moderator, needs their own deck of cards, and the planning
poker technique proceeds with these steps:

1. The product owner gives the team an overview of a

user story.
2. The team is given time to discuss and ask questions to
get a better understanding of risks and assumptions.
Team members should not mention any estimation
numbers so that estimates are not biased. The
moderator should record a summary of the discussion
and can use a timer to limit the discussion time.
3. Each team member chooses a card to represent their
estimate of the story and places it facedown on the
table.
4. Team members turn over their cards simultaneously.
 o If everybody selects the same number, you’re
done. That number is used for the estimate, and
you can move on to the next story.
o Individuals who have selected numbers that are
significantly higher or lower than other numbers
are given time to justify their estimates. For
example, the task may be simple for a developer
to complete (such as adding a field to a form),
but that simple addition could turn out to be
more complex for testers later.
5. The process repeats from step 3 until the team reaches
a consensus.
6. The next user story is introduced for estimation and
the entire process repeats.

If your team doesn’t have physical card decks, you can run
through your user story estimation process using the
template below. An online Fibonacci scale is a great solution
for distributed teams who can’t physically meet in the same
location.
Fibonacci scale example (Click on image to modify online)

Benefits of using Fibonacci Agile

estimation
When using the Fibonacci scale in Agile settings, your team
can experience the following benefits

Involve the whole team

It is important that every member of the development team
is included in the Agile estimation process. Each member
gives a different perspective that helps to hone in on a more
accurate and realistic estimation of the work required to
complete a user story.

For example, before declaring that building a web page

should only take four hours to complete, you’ll want to get
input from UX, design, development, and quality assurance.

Establish a scale for comparing story point complexity

Assigning story points with linear numbers makes it difficult

to determine how much weight each story point should carry.

For example, you can reasonably estimate that a story point

assigned the number two is twice as complex as a story point
assigned the number one. But, how much more complex is a
number 12 compared to a number 11?

The exponential nature of the Fibonacci Scale makes it easy

for the entire team to understand what the assigned numbers
mean.

For example, a 1 could mean that complexity is minimal, and

the story point can be delivered quickly (within an hour).
Several of these tasks can be completed in a day. A 13
means the story point is very complex and could take weeks
to complete.

Increase the accuracy of estimates

By assigning story points higher numbers, it forces the team

to realistically look at the complexity and effort required to
complete the task, which can lead to more accurate
estimates.
Tired of completing user stories after your projected
deadlines? Ready for more accurate estimates? Incorporate
the Fibonacci scale into your Agile planning processes now.
Overview of Agile Estimating
Absolute vs. Relative Sizing

When more is known than unknown, use absolute estimating. A

traditional or Waterfall software development lifecycle includes a long and
detailed planning period to define requirements before beginning
development. Absolute estimating is the practice of applying an hourly,
finite estimate to each requirement. Absolute estimating may seem like a
good approach when requirements are known, the environment is not
complex, and the need is not urgent. However, even if detailed requirements
are available, there are common concerns with absolute estimating.

 I know how to do it, so the size reflects my experience versus how complex
the ask
 I don’t know enough about the requirements, so the size is a measure of my
uncertainty
 I have little experience or high time pressure; therefore, the estimate is
influenced
 I am swayed by irrelevant or misleading information, such as budget, so my
estimate is biased

The antidote to ambiguity is agility. Agile approaches continue to gain

popularity because of the marketplace’s volatility, uncertainty, complexity,
and ambiguity. One of the reasons Agile frameworks work so well in complex
domains, such as software development, is the balance of responding to
change and getting something completed within specified, timeboxed
iterations. It’s a different approach than a traditional software lifecycle, but it
is necessary. In an Agile approach, the developers only know enough to get
started–they don’t know everything needed to complete an item. This
intentionally incomplete plan works because they determine what is required
through daily collaboration with the requestor during development. The more
ambiguous the requirement, the more difficult it is to calculate how long
something will take. But teams still need to estimate their work to forecast
releases.

When more is unknown than known, use relative

sizing. Unfortunately, humans are phenomenally bad at estimating and
even worse when working in a complex domain like software development.
(2006, Jørgensen and Grimstad). Luckily, people are good at comparing
things. Agile estimating uses relative sizing to provide a realistic way for
teams to forecast work. This estimating method uses the Fibonacci sequence
as a starting scale for comparing items. In the Fibonacci sequence, each
number is the sum of the preceding two numbers: 0, 1, 2, 3, 5, 8, 13, 21…
Why use the Fibonacci sequence? Borrowed from nature, this
exponentially increasing scale deliberately creates a buffer in estimating that
allows for change.

The Developers on a Scrum Team size the work they are accountable for
delivering (Developers in Scrum include anyone needed to develop the work,
including analysts, UX, and quality professionals). They discuss each request
and assign a number from the Fibonacci scale that correlates to the overall
size. They use everything they understand about the request at that point in
time and what is expected to call it complete. This method is called Story
Pointing, accredited to Ron Jeffries, an Extreme Program (XP) expert, and
Agile thought leader. While Story Points include effort, like absolute
estimating, it further accommodates the expected ambiguity of Agile
requirements. Story Points represent the complexity, uncertainty, and effort
(CUE) needed for completing or implementing each work item. The higher
the number, the more complex and uncertain the work, and presumably,
the amount of effort it will take to complete.

Using the Fibonacci scale, developers compare items to each other; the scale
is the same for everybody on the team. Over time, teams start to see the
same completion curve as various people work through items with the same
point values. For example, 1 Story Point means that CUE is minimal, and the
item can be delivered quickly, perhaps in one day or less. On the other hand,
an item assigned 13 Story Points means it is very complex and could take
multiple weeks to complete.

When using the Fibonacci scale for relative sizing, teams experience the
following benefits:

 Establishes a scale for comparing an item’s complexity, uncertainty, and

effort
 Involves the whole team; therefore, includes everyone’s perspectives
 The exponential nature of the Fibonacci Scale makes it easy for the entire
team to understand what the assigned numbers mean to them and their
unique domain

Agile Planning
Trust the Team and the Process

The whole team needs to understand the logic behind the assignment of
Story Points to reach a consistent practice. All team members vote–without
being influenced by other team members. There are plenty of techniques to
do this, such as Fist to Five voting or Planning Poker. Outside pressure or not
enough teaming can quickly artificially inflate story points, which then affects
forecasting.
Normalizing. A bit of normalization occurs through regular practice that
helps ensure everyone on the team makes the same assumptions behind
sizing. For example, if one person sizes an item at a “2”, but another person
sizes it as an “8,” given they share similar ability, they interpret the
requirement differently or approach it from different directions. When this
happens, the Developers collaborate with the Product Owner to clarify
assumptions and agree on a size. (This does not need to be a consensus –
people can agree to disagree.)

While a team is learning what the Fibonacci scale means to them, with their
unique set of skills, tenure, and domain knowledge, it is helpful to compare
new requests to completed work with shared similarities. For example, when
a new item is assigned a Story Point value of 5, compare it to similar things
with the same size, then adjust the Points accordingly.

3-touch system. Through the practice of refining, breaking work into

smaller, valuable chunks, the Developers continue to gain insight. As each
request becomes smaller and more is known, they continually revisit the
size. It’s a good practice to provide three touchpoints to help the team with
the emerging design, development, and dependency of requirements. Along
the way, revisit the Big View of the organization to ensure that strategy
continually informs development.

1. Pre-View: During Release Planning, an event where a team is looking

several Sprints ahead, items are typically substantial. Therefore, high-level
forecasting can be completed by comparing large, new work to complete
similar work.
2. Now-View: During Sprint Planning, the Developers learn more as they break
each item down into tasks and then size each task using hours.
3. Daily: As the Developers work on each item during the Sprint, they continue
to learn and daily re-forecast the remaining work against the Sprint Goal,
including any quality measures and tasks needed to achieve their Definition
of Done.
 Applying
Horizon Planning in Agile. Image by Author.

Practical Fibonacci
Getting started

The chart below may help your Developers if they are new to relative sizing
using Fibonacci. (The term Developers in Scrum includes anyone developing
the work, including business analysts, UX, and quality assurance
professionals. Getting something to Done means it meets everyone’s
expectations of Done, typically written out in the Team’s Definition of Done.)
These definitions are meant to be a starting point for a conversation.
Ultimately, your team will find their own value scale and their own language
that is meaningful to them.
Image by Author