Why would teams use the Fibonacci sequence for story points?

Why do some teams use numbers from the Fibonacci sequence as story points? Is it just a preference, or is there something more to it?

• Oct 31, 2016 at 21:18
• I think it's similar in spirit to logarithmic scales such as the Richter scale for earthquakes. And it's why we measure small distances in feet, but large distances in miles. Oct 4, 2017 at 18:59

Some teams also use powers of two, or have a scale like 1, 2, 5, 8, 20. The idea is that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be. Using the Fibonacci sequence helps teams to recognise this uncertainty, deliberately creating a lack of precision instead of wasting time trying to produce estimates that might also carry a false degree of confidence.

Dan North's blog post, "The Perils of Estimation", explains this very effectively IMO.

• However it was I believe Mike Cohn who said that they switched from 21 to 20 in their planning poker as 21 seemed "too precise" and 20 looked properly coarse-grained. Jan 4, 2012 at 21:11
• I kind of made that scale up, but it seems sensible - if estimating something you've never done before can ever be said to be sensible, anyway. Jan 4, 2012 at 23:55
• Where did 13 go? Jan 25, 2012 at 20:58
• In this instance, anything bigger than 8 contains so much uncertainty it might as well be 20. It's just another example of the kind of things people do. Jan 26, 2012 at 8:11

I would add that having the scale non-linear helps with making decisions. It's much easier to say: it's more 8 than 5 than to say it's more 8 than 7.

• So given that the scale for points is non-linear, does it then follow that any velocity derived from said points will not correlate linearly to a planned sprint (sum of points)? Moreover, a velocity of 10 does not mean that planned sprint totalling 10 is logically achievable (but merely likely to be achievable)? Jun 21, 2012 at 1:19
• Seperately, while it's easier to say "8 is more than 5" are the relationships between integers linear? ie. 8 is not just more than 5 but in fact exactly 1.6 times greater than 5? Jun 21, 2012 at 1:22
• The relationship is not linear, and that is the point. The relationship is based on orders of magnitude (which is why some teams use powers of 2). Mar 18, 2013 at 20:11
• Just to clarify (be a pedant) 7 isn't in the Fibonacci Sequence so you would never say "it's more 8 than 7" The full sequence up to 13 is 1, 2, 3, 5, 8, 13. The number 3 was missed in the sequence ergo 3+5 = 8 and not 7 Dec 10, 2015 at 13:40
• @droppin_science I think you didn't read the answer correctly… The guy was advocating the use of the fibonacci sequence by saying that using it (e.g. "more 8 than 5") makes estimations easier than with linear sequences (e.g. "more 8 than 7") May 26, 2016 at 3:31

Try this simple exercise: What's the difference between stories with consecutive scores like 5 and 6? And that between 3 and 5 or 5 and 8 or 8 and 13 or 20?

The fact that these 'buckets' are further apart imply that you are forced to make a choice between the less/more uncertain stories and choose which bucket is the most appropriate one. The human mind 'sees' a perceptible difference between 5 and 8 story points (or 13 and 20) than it does with 5 and 6 or 10 and 11.

And since the stories are relatively estimated (i.e., 20 is 4 times as much as 5) it's quite difficult to ascertain the 'ratio' of difference between a 5 and 6 than a 5 and 8 (say)

The fact of the matter is this: Increasing the interval between the numbers forces the mind to 'see' a visible difference in magnitude. More so, the variance (standard deviation) would be more pronounced than a linear scale allowing the discussions of differences to be more explicit - i.e., there wouldn't be much difference/discussions if the estimates were 4,5,6 but would be otherwise if they were 3,5,8 (say). The latter has a much higher variance.

Estimation can be done by using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

But the sequence we use most of the time is: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ?

0 indicates a user story that doesn't take up any time at all.

0.5 indicates a task that is smaller then the smallest task previously estimated. This often results in changing the previously estimated items to a higher value so the task voted 0.5 gets a value of 1.

20 replaces 21 because the estimation can't be accurate to +/-5%, and 21 seems very precise, whereas a nice round number like 20 seems like what it - an estimate.

bigger than 20 in my opinion, all tasks bigger then 20 should be split up into smaller user stories, as they are too big to be estimated with any accuracy.

? is used when people don't know understand the user story or more info is required

• We almost never exceed 13, and even 8's are considered "large". For us, a 13 is definitely a candidate for splitting up. We strive to keep our stories at 5 and below. Mar 16, 2013 at 4:12
• When can a story not take any time? Can you give an example? My understanding is that if there's nothing to do, it's not relevant to a sprint. Aug 6, 2014 at 10:55
• A textual fix, moving something by 5 pixels, changing a config setting may all end up as 0 points. These kind of very small items will skew your scale too much, if given .5 or 1 points. You may bundle them up into something bigger like "Fix a lot of small typo's" and take advantage of the slightly larger size, fixing 1 textual bug means context switching, fixing 50 textual bugs provides focus and a clear goal. O a 0 point story may be solved together with a larger story (say 5 points). Mar 8, 2015 at 17:52

Because the complexity of interactions in a system scales non-linearly with the number functional components.

To a first approximation, let's say you have three components in a system that all interact with each other. That's 3 "interface points" that might cause you to have to change the components to all work correctly with each other. If you have four components, it's not 4 interface points, it's 6, and with 5, it's 10, etc. In general, a complete graph with n nodes (all nodes collaborate directly) has n(n-1)/2 edges, so a system with all components talking to each other has n(n-1)/2 interactions.

n 1 2 3 4 5 6 7
Fibonacci 1 1 2 3 5 8 13
n(n-1)/2 (hypothetical ideal) 0 1 3 6 10 15 21
2^n 2 4 8 16 32 64 128

[edited table based on comment]

As you can see, Fibonnacci tracks, but "falls behind", while powers of two wildly overestimate things with more than 5 components. In the end, Fibonacci is usually chosen because in most systems, n(n-1)/2 over-estimates the number of real interactions in your system: rarely do all components interact with each other directly in a real-world application.

• Trivial, but the 4th term in n^2 sequence should be 8 Jul 8, 2014 at 17:05
• This is a cool way of looking at it Jun 21, 2020 at 2:40

During a meeting, it occurred to me to use the value of the Euro coins and bank notes greater or equal than 1,00 €:

• 1
• 2
• 5
• 10
• 20
• 50
• 100
• 200
• 500

UPDATE:

A colleague replied to me this was great because it is a scale that everyone already knows and people don't need to invent a new artificial scale, and even better do not need to have the scale always in their front.

• I am not sure that this answers the question, however if you can explain why this is better than the Fibonacci sequence, it may be worthy of note. The key is explaining why, rather than simply offering an alternative. Mar 5, 2015 at 18:16
• @Iain9688: In the Update, I say it. It wasn't even me that acknowledged the advantages, it was my colleague. Mar 6, 2015 at 14:33

I understand this is an old thread, but I thought I could provide some insight.

Key Idea

Suppose you want to know how long a task will take. You take a look at the problem and estimate that it will be one hours worth of difficulty/complexity. At the end of the hour it's not done. You've realized something about the problem and it's as if you are starting over. What is a reasonable/minimal estimate of the time it will now take? Thinking for a moment, you realize it should be the amount of complexity you already knew about plus the complexity you just discovered. At this point the old complexity was zero, so you add 1 and 0 to get your new estimate of 1. Continuing in this fashion you obtain the following Fibonacci Sequence:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ...

Each step satisfies the following golden ratio since the sequence yields the most efficient next estimate

a+b / a = a / b

Or more explicitly

new_estimate_of_complexity = new_complexity + old_known_complexity

new_estimate_of_complexity / new_complexity = new_complexity / old_known_complexity

Further Issues

But then you ask, does it mean that it is always as if I'm starting over? People will get upset if I have to tell them that I thought it was going to take 8 hours but now it will take 13 more. Thinking for a moment one realizes that if we only update the time, so that estimating 13 when we had 8 only adds 5 more hours, then it is as if the sequence is reversed.

..., 55, 34, 21, 13, 8, 5, 3, 2, 1, 1, 0

The same logic still applies. It's as if we started with one of these higher numbers and we're giving smaller estimates as time went on.

Furthermore, we can scale each number in the sequence by the same amount, say 8.

0, 8, 8 (2 days), 16 (four days), 24, 40 (one work week), 64, 104 (~ 2.5 weeks), 168 (~ one month), 272, 440 (a sprint), ...

This scaling number accounts for how long the problem solver needs to understand and reason about the problem. On the average, per individual and across individuals, 8 hours is usually the best starting point, since it strikes a balance between all of the following issues:

1. Risk of giving estimates that are to short.
2. Risk of giving estimates that are to long.
3. Accounting for interruptions.
4. Error in estimating the complexity of a problem.
5. The problem statement changing mid stream.
6. Etc.

What it is not

It is not about uncertainty in the task. Quite the opposite, it's about what we know. Known complexity.

It's not about human perception, but it does have the side effect of influencing our perceptions. Yes 13 really does seem bigger than 8 without being to much bigger.

It's not about guessing, which people commonly assume when they guess at the scaling factor. Clearly, identifying this number could be made more rigorous.

Scaling is not the same as using a different multiple such as 2. This would effectively subsume the Fibonacci Sequence, which we know is accounting for what is known about the complexity of the problem. Other sequences, are making assumptions about the unknown as well as the known, which is why they are inefficient.

Splitting into smaller stories in order to reset the clock, is not necessary nor beneficial. Can anyone make this problem smaller than what it really is? Does anyone have a time machine so I can go back an make up my hours? No on both counts. But when you reset the clock, you are hiding how risky of a problem it happens to be. A problem, that is legitimately estimated to be 8 hours, is the same as one with 8 hours after resetting from 440 hours.

References

• How does 8 = 2 days and 16 = 4 days when 40 = 5 days and 104 = 13 days? Feb 21 at 16:33

I think story points for a task is in fibonacci so that it can be decomposed into two (or more) smaller sub-tasks with appropriate story point. Ex. Say I assigned 21 story points to a task. Later I realized that this task can be broken down into 2 smaller sub-tasks. So, I can create 2 sub-tasks with story points 8 and 13. This way I can easily manage 2 sub tasks (with its own story points) without affecting the total story points I took for the bigger task in a sprint (which was 21 in this case).

I think if we put this in a better perspective and we draw the spiral out it shows a better perspective of time spent. So if I go 1 to 2 that is a very small circle in a time frame, but if I go from 1 to 21 and look at the arc it becomes much better to understand in time spent. So although hard to explain with out graphics, take a compass (you remember those) put it on 1 as your point then circle it to your next number or point value and you will get a much better picture of time spent.

• Hey David, welcome to Project Management SE. I suspect you're compass analogy could be valuable, but to make this a more complete answer, you may want to address why teams would use the fibonacci sequence for story points. On our platform, answers get ordered randomly or voted to the top, so it's important they all answer the question for context. For more details on how our site works, please see tour. Good luck and thanks for participating. Apr 20, 2014 at 1:44

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

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.

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.

(This answer is based on my comments to a similar question on Stackoverflow here.)

I agree with Amit Kumar "story points for a task is in fibonacci so that it can be decomposed into two (or more) smaller sub-tasks with appropriate story points" In fact I would go one step further and say if we have a 13 point story we should be asking can we decompose it into two stories 8 + 5 or 5 + 8. This "tests" the idea that 13 is a "good" estimate and the decomposition helps management.