91

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?

11 Answers 11

87

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.

|improve this answer|||||
  • 4
    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. – Pawel Brodzinski Jan 4 '12 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. – Lunivore Jan 4 '12 at 23:55
  • 1
    Where did 13 go? – ashes999 Jan 25 '12 at 20:58
  • 3
    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. – Lunivore Jan 26 '12 at 8:11
46

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.

|improve this answer|||||
  • 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)? – cottsak Jun 21 '12 at 1:19
  • 1
    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? – cottsak Jun 21 '12 at 1:22
  • 3
    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). – Andrew Clear Mar 18 '13 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 – droppin_science Dec 10 '15 at 13:40
  • 2
    @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") – cedbeu May 26 '16 at 3:31
20

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.

|improve this answer|||||
18

In addition to the answer of Lunivore:

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

|improve this answer|||||
  • 1
    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. – Bryan Oakley Mar 16 '13 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. – Mentatmatt Aug 6 '14 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). – jessehouwing Mar 8 '15 at 17:52
6

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.

1, 1, 2, 3, 5, 8, 13 <- Fibonnacci
0, 1, 2, 3, 6, 10, 15 <- n(n-1)/2 (hypothetical ideal)
2, 4, 8, 16, 32, 64, 128 <- 2^n   

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

|improve this answer|||||
  • Trivial, but the 4th term in n^2 sequence should be 8 – Ed Griebel Jul 8 '14 at 17:05
5

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.

|improve this answer|||||
  • 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. – Iain9688 Mar 5 '15 at 18:16
  • @Iain9688: In the Update, I say it. It wasn't even me that acknowledged the advantages, it was my colleague. – sergiol Mar 6 '15 at 14:33
3

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

  1. Golden Ratio
|improve this answer|||||
2

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

|improve this answer|||||
1

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.

|improve this answer|||||
  • 1
    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. – jmort253 Apr 20 '14 at 1:44
1

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

|improve this answer|||||
0

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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.