Why are Fibonacci Numbers used in Story Point Estimation?

Developers and Estimation:

One of the aspects of a Scrum Development Team is to self-organize themselves and are expected to manage their own work. A crucial aspect is to estimate their work so that it gives predictability to the Product Owner and Stakeholders. In Scrum teams, two estimation approaches are commonly used: Ideal Hours and Story Point estimation.

The 'Ideal Hours' approach consists of estimating effort what we know today, and how long it would take if everything goes according to the plan. And since humans are not so great at estimating in terms of hours, usually Developers tend towards using Story Points which is a measure of the relative size of a User Story based on whatever information is known now.

In Agile projects, Story Points are used as units of work to estimate the complexity of a given User Story. An excellent way to size a User Story is to articulate it in terms of a known User Story or also called a reference User Story. This makes it easier for each Development Team member to size the relative complexity. This process of comparing a User Story with a previously estimated User Stories is known as triangulation.

Size:

The size of a User Story is a combination of 3 factors - C U E:

• Complexity
• Uncertainty - Lack of clarity of the User Story
• Effort

Developers may use one of the following series to size the User Stories in a Product Backlog:

• Natural numbers: 1, 2, 3, 4, 5 and so on.
• Even numbers: 2, 4, 6, 8, 10, and so on.
• Fibonacci series: 0, 1, 2, 3, 5, 8, 13, 21, 34 and so on.
• Modified Fibonacci series: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
• Or any other series.

Amongst these, the Modified Fibonacci series is the most popularly used series for sizing.

What are Fibonacci numbers?

The Fibonacci series consists of a sequence of numbers where each number is a sum of the preceding two numbers. The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34 and so on. In Agile projects, this series is modified. The modified Fibonacci series is 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 - a sequence that is used to estimate the relative size of User Stories in terms of Story Points.

Significance of the Fibonacci numbers in Agile sizing:

They are exponential

When estimating time, a shorter time span indicates more certainty (or clarity in the User Story), whereas bigger work items are more complex, and time estimates turn out to be less precise. An exponential scale enables just enough details for small tasks and indicates more uncertainty for large tasks.

User Stories with smaller sizes (less complexity and more clarity) can be estimated more effectively compared to User Stories that are more complex. As the numbers increase, the difference between two succeeding numbers also increases exponentially, which leads to less realistic estimates. This is similar to the characteristics of User Stories (or Product Backlog Items) whose complexity also increases as we move deeper into the Product Backlog.

The Fibonacci sequence is a lagging exponential sequence. It enables you to develop your estimates with increasing uncertainty as time increases, which results in an effective, efficient estimation.

Using the Fibonacci series turns out to be helpful in such cases because larger User Stories that lead to inconsistent estimates between team members can be now requested to break down into smaller User Stories. They can also be grouped to the nearest Fibonacci number of the analogous bucket in the backlog. Smaller User Stories have a smaller bucket difference, which results in a more realistic size (C U E).

They consist of integers

In Agile, both requirements and solution evolve over a period of time. So are the estimates (sizes of User Stories). The goal of sizing is to get a high-level estimate and get started. Thus, there is no need for the level of detail at a detailed decimal level. Trying to be accurate may slow down the team. After all, the Cone of Uncertainty says that the actual sizes of User Stories end up somewhere between +160% and -160% of the initial estimated sizes.

You need to choose more or less

Besides adding uncertainty for larger time spans, the Fibonacci sequence also compels your team to make a choice. For unclear User Stories, there has to be a 'this' or a 'that', and nothing in-between, which encourages your team to group and differentiate the size of User Stories. Moreover, the Fibonacci sequence has a varying distance between Story Points. For instance, the difference between 3 and 5 is 2, while the difference between 5 and 8 is 3. This enables you to intuitively differentiate the Fibonacci numbers as different magnitudes.

They are non-linear

Fibonacci numbers are non-linear in nature, which reduces the probability of over-analysis. Some of these numbers used in the Fibonacci sequence are prime numbers, which restricts your ability to compare or evenly break down tasks. Large User Stories are not squarely linked to each other, and the numbers don't indicate that the User Story would be twice as fast if you have multiple people working on it. This mitigates the chance of over-analysis.

Implementing Fibonacci-Based Estimation in Agile Teams

Understanding the theory behind using Fibonacci numbers is essential, but how do you implement this with your Agile team? Let's explore a step-by-step approach to effectively implementing Fibonacci-based estimation.

1. Conducting Planning Poker Sessions

A popular method for Agile estimation is Planning Poker, which leverages the Fibonacci sequence to assign story points. Here's how you can facilitate a Planning Poker session:

• Preparation: Gather your team and ensure everyone has a deck of cards representing the Fibonacci sequence (e.g., 1, 2, 3, 5, 8, 13, 21).
• Discussion: Present a user story to the team. Encourage a conversation to clarify details, assumptions, and potential challenges.
• Estimation: Each team member privately selects a card reflecting their estimate of the story's complexity and effort.
• Reveal: All members reveal their selected cards simultaneously.
• Consensus Building: If estimates are significantly disparate, facilitate a discussion to understand the reasoning behind different perspectives. Repeat the process until the team reaches a consensus.

This technique not only promotes collaborative estimation but also helps uncover aspects of the user story that might not have been initially considered.

2. Embracing Relative Sizing

Fibonacci-based estimation emphasizes relative sizing over absolute time measurement. Instead of asking, "How many hours will this take?" you assess, "Is this task more complex than the previous one?" This approach acknowledges the inherent uncertainty in software development and focuses on comparing tasks to each other.

3. Addressing Estimation Challenges

While Fibonacci-based estimation offers structure, it's essential to be aware of potential challenges:

• Overemphasis on Numbers: Remember, the numbers are guides. Avoid getting bogged down by the numerical values; focus on the relative differences between tasks.
• Team Dynamics: Ensure all team members feel comfortable voicing their opinions during estimation sessions. A dominant voice can skew the estimates and undermine the collaborative nature of the process.
• Continuous Calibration: Regularly revisit and adjust your estimation process. As your team evolves, so might your understanding of complexity and effort.

Implementing this estimation technique can lead to several advantages. You can improve your estimation accuracy and encourage teams to perform consistent Sprint Planning for workload distribution. Ultimately, it /helps to deliver your agile projects successfully within the planned time!

Wrapping it up

Developers can have different experiences with different estimating sequences depending upon the sequence they use. However, majority of the Developers measure User Story in terms of relative size which is a combination of 3 factors namely C-Complexity, U-Uncertainty and E-Effort.

The technique that is used to size User stories is called Planning Poker. Developers play Planning Poker during Product Backlog Refinement, and during Sprint Planning if required. A Scrum Master facilitates Planning Poker and helps Developers makes decisions, while a Product Owner clarifies questions raised by the Developers.