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?
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.
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.
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
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.
During a meeting, it occurred to me to use the value of the Euro coins and bank notes greater or equal than 1,00 €:
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 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.
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.