Why is the Fibonacci series used in agile planning poker? [closed]

Question

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.

Convertite

Probably just because the Fibonacci sequence is "cool". Any exponential sequence would work. 2^n might space the numbers too far, so why not use the Fibonacci sequence, which is about c*phi^n? – Squib

+1 for 'is cool'. I've worked with programmers before who always wanted to push oddities into Fibonacci - it was always their 'thing' – Apart

duplicate of pm.stackexchange.com/questions/4251/… – Trotter

This question appears to be off-topic because it is about...? – Burmeister

Answer 1

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

Gunzburg

This is a deeper explanation I was hoping for. Thank you for this answer. – Convertite

“[a] little estimation effort helps a lot and [a] big estimation effort helps little” great article – Mattison

Answer 2

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.

Colver

That is an interesting point of view. But why then isn't the series of prime numbers 1,2,3,5,7,11,... used for estimating instead of the Fibonacci series? – Convertite

That's an excellent idea. Actually, they occur frequent enough to only pick those that roughly create a [1.5-2.0]^n series. Fibonacci numbers are admittedly easier to recreate from head, but tools like JIRA allow to specify any set of values. – Colver

The other point is the distance between estimates. The larger time you're estimating the less certainty there is. Between 3-5 and 5-7 is the same difference, implying the same certainty. But when you have to choose between 8 and 13 (a larger gap), it forces you to really examine how certain you are. – Handstand

@Convertite I think it's because fibonacci numbers are exponential where as prime numbers are linear for the small sample that is typically used when estimating stories – Bridesmaid

Answer 3

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...

Tropho

This answer is almost exactly the same (references the same link and the same quote) as the answer from @kaj that was two months earlier. – Bridesmaid

i really liked the way this person quoted it. made me understand instantly. – Laureen

Answer 4

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...

Hambrick

"The precision of your estimation as well is very likely to be proportional to your estimation." Is this a rule in statistics or is this something humans normally do? If you use Fibonacci numbers, you assume, that the relative error of an estimation is about f(n-1)/f(n) = 1-goldenratio = 61 %. So if one estimates 5, people assume this implies a relative error of about 3, so a significant increase in complexity would only be 8 or higher. However, why is the relative error assumed to be about 60%? Is this just a rule of thumb? – Convertite

To answer my own comment: Mike Cohn (November 2005). "Agile Estimating and Planning" says: "Studies have shown that we are best at estimating things that fall within one order of magnitude (Miranda 2001; Saaty 1996)". – Convertite

Miranda (2001): "Improving Subjective Estimates Using Paired Comparisons" says: "I conducted an informal survey among colleagues; 30 people from different countries and from both industry and academia provided input for the scale. The results suggest that the correspondence between size and verbal description in the software domain is closer to the one shown in Table 3 than to Saaty’s." And in this table we see that something is called "slightly bigger" if it is 125% of the base size and it is called "bigger", if it is 175% of the base size. – Convertite

The next Fibonacci number is 161% of the former Fibonacci number, so this fits in between "slightly bigger" and "bigger" in Mirandas table. It seem this informal survey is the root of why we use Fibonacci numbers, because their ratio is closer to what we mean if we say something is bigger. – Convertite

@Convertite I think you should add these comments as a separate answer, they're excellent, or perhaps on the linked PM.SE question as this unfortunately is locked. – Bridesmaid

@Bridesmaid On your suggestion I posted my comments now as answer at pm.stackexchange.com/a/23409/8693 . – Convertite

@Convertite I've upvoted :) – Bridesmaid

Answer 5

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.

Counterforce

Answer 6

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.

Tishtisha