Why Fibonacci for Story Points: Magic Dispelled

While mystery enhances magic tricks, it complicates estimation. Without understanding this scale’s origin and benefits, its value to your team remains dubious.

Story Points Scale

A Story Points Scale encompasses a spectrum of potential values that agile teams use to gauge the size of a user story. While development teams commonly adopt the Fibonacci series, alternative options also exist.

Some teams use a linear scale (1, 2, 3, etc.) composed of any positive real number. Others use multiplies of two (2, 4, 6, etc.). Some teams stick with whatever the default values are from their project management software.

Since story points evolved from Ron Jeffries’ need to obfuscate ideal days, there isn’t a definitive rule book or guide on how to use story points. If your Scrum Team has chosen to use story point estimation, feel free to experiment with different scales to determine what provides the most value to your team.

When Mike Cohn created his planning poker deck of cards, he had to pick a sequence. At the time, he slightly preferred the modified Fibonacci series. These popular card decks have contributed to the popularity of using the Fibonacci series for story points. Still, even by Cohn’s admission, there were no significant benefits of using one standard sequence versus another.

What Is the Fibonacci Sequence

The Fibonacci Sequence is a series of numbers where each number is the sum of the two preceding ones. It starts with 0 and 1, and each subsequent number is the sum of the previous two. This sequence appears in various natural phenomena and mathematical concepts.

The first 15 numbers in the series are as follows:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377

It might come as a surprise, but most teams utilizing the Fibonacci sequence for estimation employ a modified version rather than the original Fibonacci scale.

Modified Fibonacci Sequence

The Modified Fibonacci Sequence is a variation of the traditional Fibonacci sequence, tailored for agile estimation. It retains the essence of exponential growth while addressing some complexities arising during agile estimating.

Common modifications include:

• Adding a 1/2 fraction for small tasks.
• Removing the redundant second one.
• Simplifying the numbers in the upper sequence to make it more memorable.

What Is an Example of a Modified Fibonacci Sequence

The most common modified Fibonacci sequence I’ve experienced includes 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100.

This estimating sequence was popularized by Mountain Goat Software’s planning poker cards and Mike Cohn’s book Agile Estimation and Planning.

While the Fibonacci sequence is a foundational mathematical concept, the notion of adapting it has gained prominence through agile teams. As you might expect, various iterations of this adaptation exist, lacking a singular standardization.

Why Is the Modified Fibonacci Sequence Used When Estimating

A Modified Fibonacci Sequence empowers teams with a tailored progression to depict complexity gradations more precisely, all while streamlining upper limits for enhanced memorability.

By the time we incorporate all the modifications, the resulting sequence will likely deviate significantly from the original Fibonacci sequence. Despite the considerable adjustments applied, the Fibonacci scale still provides a valuable initial reference that reinforces the concept of relative sizing. Moreover, the typical adjustments align to enhance estimation efficiency.

Incorporating a zero, the renowned agile estimation scale raises an intriguing question: When was the last instance of work requiring absolutely no effort? Recognizing that nothing in life truly comes for free, some teams opt against including zero as a potential size, reflecting a desire to acknowledge even the slightest effort in their estimations.

Balancing the intricacies of estimation, zero can feel minuscule, and one, occasionally excessive, especially when contrasting smaller work items against those previously assigned a value of one story point. As a response, teams frequently introduce a value of 0.5, bridging the gap between these extremes and fostering more nuanced estimations.

The initial Fibonacci sequence features a pair of ones: 0, 1, 1, 2, and so forth. This quirk occasionally prompts teams to playfully ponder whether they’re referencing the first or second one when sizing requirements—a classic Agile dad joke. In practice, a single one suffices as a viable option.

While the Fibonacci Scale can theoretically extend infinitely, with each subsequent number being the sum of the previous two, this endless progression loses practicality in estimating Product Backlog Items. Recognizing this, most teams establish an upper limit, understanding that an infinite scale isn’t conducive to the Backlog Refinement process.

Beyond establishing an upper limit, teams commonly opt to modify the concluding values of the sequence, a practice that holds multifaceted benefits. Firstly, this modification often simplifies the series, aiding the development team’s memory retention of potential values.

Secondly, this alteration lends a more generic quality to the values, mitigating any misleading sense of precision that might arise from specific numbers.

The second benefit of modifying the concluding values extends beyond the mere rationale for its modification; it also interweaves with several advantages of employing the sequence itself.

Precision Creates the Illusion of Accuracy

By removing the allure of specificity that specific numbers might carry, teams steer clear of the pitfall of falsely attributing unwarranted accuracy to their estimations.

In Thinking in Bets, Annie Duke highlights how people view predictions as certain, known outcomes, overlooking the uncertainty and probabilities involved. This cognitive bias narrows our perspective, ignoring the possibility of a middle ground. Teams should be cautious using precise story points (like 21, 34, 55, 89) as they can falsely imply certainty, masking the probabilistic nature of estimations.

Perpetuating the notion that story point estimates are anything other than a guess can lead to team dysfunctions such as deadline-driven development, fear of experimentation, the blame game, or obsessing over the imaginary Sprint commitment.

Uncertain how precision suggests accuracy? Consider if you inquired about chicken cooking time. If I replied, “Under half a day,” you might sense uncertainty. However, stating “forty-two minutes and seventeen seconds” might suggest uncanny clairvoyance in gauging chicken cooking time.

The precision of my response implies a sense of confidence or accuracy that is not guaranteed.

Why Use Fibonacci for Story Points

“Planning is a form of necessary waste. It doesn’t create much value all by itself. Work on gradually reducing the percentage of time you spend planning.”

- Kent Beck, Extreme Programming Explained

Leveraging an estimation scale can help us sidestep typical estimation challenges, cutting down the time invested in an activity that doesn’t directly benefit the user.

Faster Estimation

Confronted with a linear scale of numerous possibilities, developers often spend time deliberating the most precise size representation. Reducing the potential values to a handful typically expedites the process of sizing Product Backlog Items.

Relative sizing further enhances estimation speed. While deliberating between a five and a six can be challenging, it’s simpler to determine if a requirement aligns more with a five than an eight. The scale’s increments facilitate swift and efficient decision-making.

Complexity Doesn’t Grow Linearly

When we size a story, the story point value we end up with is not a cardinal value but an ordinal one. It comprises four concerns: complexity, uncertainty, risk, and effort.

Complexity doesn’t increase in a straight line, so adopting the Fibonacci sequence for estimating user stories is beneficial. As requirements become more intricate, the size should expand faster than a linear progression.

Works Consulted

• Scrum Guide
• Story Points Revisited
• Why the Fibonacci Sequence Works Well for Estimating

TLDR

Beware of falling into the illusion of magic and uncritically adhering to industry norms advocating for the use of the Fibonacci sequence. If this approach proves more problematic than advantageous for your team, consider exploring alternate scales (such as powers of two) or different agile estimation techniques. You might even delve into flow metrics or consider abandoning estimates on user stories altogether. The Scrum Guide doesn’t mandate story points but strongly encourages experimenting with your processes to find what suits your team, culture, and circumstances.