Scrum, a widely adopted Agile framework, doesn’t place a lot of emphasis on accurate estimation. However, estimation can provide teams with better insights into the effort required to deliver features, including risks and dependencies. And this can enable better planning and risk management. Within this context, the Fibonacci sequence has emerged as a popular tool in Scrum estimation. But why does Scrum gravitate towards Fibonacci numbers, and how does it enhance the estimation process?
This article will explain why does Scrum use Fibonacci numbers:
A Scrum Development Team is not just a group of developers; they are a cohesive unit responsible for delivering increments of potentially releasable functionalities. Their role extends beyond coding; it encompasses understanding requirements, designing solutions, testing, and ensuring the final product aligns with the user’s needs.
In Scrum, teams are self-organizing, meaning they decide how to accomplish their work rather than being directed by others outside the team. This autonomy means a team might need a robust estimation mechanism to help with predictability and reliability in deliveries.
Traditionally, teams estimated work in terms of ‘Ideal Hours’—the number of hours a task would take without any interruptions. However, humans are notoriously bad at estimating time. Enter ‘Story Points’, a unit that measures the relative size of a user story. Instead of focusing on hours, teams assess the complexity, using the Fibonacci sequence as a guide.
Story Points offer a more abstract, yet effective, method of estimation. They represent the effort required to implement a user story. The beauty of Story Points lies in the process of triangulation. Teams compare a new user story with previously estimated stories, ensuring consistency and accuracy in their evaluations.
When sizing a user story, three primary factors come into play:
Teams have experimented with various series for estimation:
Of these, the Modified Fibonacci series is particularly favored in Agile due to its ability to capture the uncertainty and complexity inherent in larger tasks.
The Fibonacci series is a sequence where each number is the sum of the two preceding ones. While the traditional sequence is 1, 2, 3, 5, 8, and so on, Agile projects often use a modified version to better estimate the relative size of User Stories in terms of Story Points.
This modified version is usually comprised of the numbers 1, 2, 3, 5, 8, 13, 20 and 40. The numbers 20 and 40 are much easier to remember than 21 and 34, which would be the next numbers in the sequence.
The SAFe (Scaled Agile Framework) system strongly recommends using this “modified Fibonacci” sequence, and it has become a common pattern.
Fibonacci numbers are exponential, making them perfect for Agile estimations. Smaller tasks, which are clearer, can be estimated with more precision. In contrast, larger tasks, which are inherently more uncertain, are given broader estimates.
As tasks become larger, the difference between consecutive Fibonacci numbers grows, reflecting the increasing uncertainty associated with bigger tasks.
Using the Fibonacci series, teams can break down larger user stories into smaller, more manageable chunks, ensuring more accurate estimations. The rapidly growing nature of the numbers encourages this breaking down of bigger items into smaller ones.
In Agile, estimations evolve. The goal is to start the work, not to get bogged down in decimal-level details. Fibonacci’s integer-based approach aligns perfectly with this philosophy. There is no point arguing over whether something is 2.1 or 2.6 points, and with Fibonacci numbers, that isn’t possible.
The Fibonacci sequence forces teams to make decisions. For ambiguous user stories, the sequence’s increasing intervals compel teams to make a clear choice in sizing, avoiding in-between estimates.
Fibonacci numbers are non-linear, discouraging over-analysis. They remind teams that doubling the team size won’t necessarily halve the completion time.
Different teams have varied experiences with estimation sequences. However, many find that measuring User Stories in terms of relative size—using factors like Complexity, Uncertainty, and Effort—provides the most accurate results. The technique of Planning Poker, often facilitated by a Scrum Master, incorporates Fibonacci numbers to size User Stories, with the Product Owner providing clarity as needed.
Learn more about becoming a Certified Scrum Master
Dive deeper into the role of a Scrum Product Owner
Take your Scrum Master skills to the next level