If you’ve come across Scrum, you’ve probably seen Fibonacci numbers. They are very popular and widely used in Scrum circles. And in other agile frameworks also. If you’re wondering why does Scrum use Fibonacci numbers, this article will explain why. The answer might surprise you! So let’s get right into it.
The Fibonacci sequence is a famous pattern of numbers. The rule is very simple: starting with a base of 0 and 1, each next number is the sum of the previous two numbers.
So you have 1 (0 plus 1 is 1), then 2 (1 plus 1 is 2), then 3 (2 plus 1 is 3), then 5 (3 plus 2), then 8, and so on. So it goes 1, 2, 3, 5, 8, 13, 21, and so on.
The Fibonacci sequence is well known by mathematicians and scientists. It is related to the famous “Golden Mean” ratio, which is found in music, art, architecture, and more.
That’s a great (and important) question. The short answer (surprisingly) is no! The longer answer is a “kind of yes”.
The short answer is no because Fibonacci numbers are actually not part of Scrum. The Scrum Guide describes everything that is in Scrum. And if you do a search in the Scrum guide for “Fibonacci”, you will get zero results.
Scrum, of course, is a framework. That means that teams using the Scrum framework might find and use various practices. And one of those practices is using FIbonacci for story point estimation.
Now in today’s software development world, Fibonacci numbers are very widely used by Scrum teams. We will get to how and why in a minute. It is a very common practice by Scrum teams, but not actually part of the Scrum framework.
Just like Kanban boards, swimlanes, user stories, acceptance criteria, and so on. (Many of these are practices used by people using other agile frameworks, like Extreme Programming).
So that’s why the short answer is “no” but the longer answer is “actually yes”.
But how and why are they used? It’s quite straightforward. Fibonacci numbers are used when doing story point estimation. So when Scrum teams come up with a story point estimate (usually via planning poker), they use FIbonacci numbers for those estimates.
That is, they estimate on a scale of 1, 2, 3, 5, 8, 13, 21. Going over 21 is usually a bad idea. So that’s as high as you’re likely to see.
Why does Scrum use Fibonacci numbers though? There are a few reasons.
If teams are doing lots of estimation (e.g. with planning poker), you want this to be a pretty quick and simple affair. Nobody wants to spend three hours arguing over whether those stories are 5 or 6 points. Having less estimate choices makes this go more quickly and smoothly.
People freak out when the numbers start shooting up quickly. That’s a good thing! It encourages people to stop and think about how they could break something up. If a team could estimate anything, they might say something is a 9. But if you tell them that the next number up from 8 is a 13, they might think twice and break it into smaller items. And smaller backlog items are good. They reduce risk and improve flow.
The last benefit is a subtle but powerful one. Remember, the Fibonacci series increases exponentially as it goes up the scale. This shows that our uncertainty around estimation goes up as the size of the thing we are estimating goes up. Think about it this way. It is very easy for us to judge the relative difference between a two storey building and a three storey building, right? You can easily see that the three story one is one and a half times the size of the two storey one.
But what if there was a 14 storey building and a 19 or 20 storey building? It is much harder to judge the relative size between two things if they are larger and further apart. The Fibonacci sequence reflects and builds in this risk and uncertainty by increasing the numbers. You can’t specify 14 or 15, you have to jump from 13 to 21.
In summary, there are some very good reasons why Scrum uses Fibonacci numbers. Though keep in mind, they are simply a practice that many Scrum teams use. You don’t have to. You can use t-shirt sizes or days or random numbers or whatever you want. But Fibonacci numbers make a good practice patter by encouraging teams to think about size and risk as they perform estimation.