Why is the Fibonacci series used in agile planning poker?

When estimating the relative size of user stories in agile software development the members of the team are supposed to estimate the size of a user story as being 1, 2, 3, 5, 8, 13, ... . So the estimated values should resemble the Fibonacci series. But I wonder, why?

The description of http://en.wikipedia.org/wiki/Planning_poker on Wikipedia holds the mysterious sentence:

> The reason for using the Fibonacci sequence is to reflect the inherent > uncertainty in estimating larger items.

But why should there be inherent uncertainty in larger items? Isn't the uncertainty higher, if we make fewer measurement, meaning if fewer people estimate the same story? And even if the uncertainty is higher in larger stories, why does that imply the use of the Fibonacci sequence? Is there a mathematical or statistical reason for it? Otherwise using the Fibonacci series for estimation feels like CargoCult science to me.

The Fibonacci series is just one example of an exponential estimation scale. The reason an exponential scale is used comes from Information Theory.

The information that we obtain out of estimation grows much slower than the precision of estimation. In fact it grows as a logarithmic function. This is the reason for the higher uncertainty for larger items.

Determining the most optimal base of the exponential scale (normalization) is difficult in practise. The base corresponding to the Fibonacci scale may or may not be optimal.

Here is a more detailed explanation of the mathematical justification: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html

Out of the first six numbers of the Fibonacci sequence, four are prime. This limits the possibilities to break down a task equally into smaller tasks to have multiple people work on it in parallel. Doing so could lead to the misconception that the speed of a task could scale proportionally with the number of people working on it. The 2^n series is most vulnerable to such a problem. The Fibonacci sequence in fact forces one to re-estimate the smaller tasks one by one.

According to this agile blog > "because they grow at about the same rate at which we humans can perceive meaningful changes in magnitude."

Yeah right. I think it's because they add an air of legitimacy (Fibonacci! math!) to what is in essence a very high-level, early-stage sizing (not scoping) exercise (which does have value).

But you can get the same results using t-shirt sizing...

You definitely want something exponential, so that you can express any quantity of time with a constant relative error. The precision of your estimation as well is very likely to be proportional to your estimation.

So you want something : a) with integers b) exponential c) easy

Now why Fibonacci instead of, 1 2 4 8? My guess is that it's because fibonacci grows slower. It's in goldratio^n, and goldratio=1.61...

The Fibonacci sequence is just one of several that are used in project planning poker.

It is difficult to accurately estimate large units of work and it is easy to get bogged down in hours vs days discussions if your numbers are too "realistic".

I like the explanation at http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/, namely the Fibonacci series represents a set of numbers that we can intuitively distinguish between them as different magnitudes.

I use Fibonacci for a couple of reasons:

• As task gets larger the details become more difficult to grasp
• Task estimate is the number of hours for anyone in the team to complete the task
• Not everyone in the team will have the same amount of experience for a particular task so that adds to the uncertainty too
• Human gets fatigue over larger and potentially more complex task. While a task twice as complex is solved in double time for a computer it may take quite a bit more for a developer.

As we adds up all the uncertainties we are less sure of what the hours actually should be. It ends up easier if we can just gauge if this task is larger/smaller than another one where we gave a estimate of already. As we up the size/complexity of the task the effect of uncertainty is also amplified. I would be happily taking an estimate of 13 hours for a task that seems twice as large as one I've previously estimated at 5 hours.