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.
|n(n-1)/2 (hypothetical ideal)||0||1||3||6||10||15||21|
[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 understand this is an old thread, but I thought I could provide some insight.
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
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:
- Risk of giving estimates that are to short.
- Risk of giving estimates that are to long.
- Accounting for interruptions.
- Error in estimating the complexity of a problem.
- The problem statement changing mid stream.
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.
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.