What is the reason for using Fibonacci numbers to estimate effort for Agile projects?
I know this is not strictly testing related, but testers are still part of the planning and understanding of this is useful when estimating testing effort.
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.Sign up to join this community
They reflect that the degree of uncertainty grows as you look further out and at bigger tasks with more dependencies.
For example, today you can be reasonably confident about how much effort is needed for a small task. You may be highly confident that you can finish it within a day, and, critically there is little uncertainty about the factors involved. So it is easy to say this should be a 3 rather than a 2, or a 1 rather than a 2 with a reasonably high degree of certainty. Humans are involved and they have many variable factors to consider.
When you look further out, and at bigger tasks, uncertainty becomes MUCH greater. Many other dependencies are involved and many of them have uncertainties.
Given this, one learns that trying to be accurate about the future this way, for exampling estimating that a task will take 18 days instead of 17 is likely to be a foolish endeavour because, 18 days out you are unlikely to have the information to make an accurate estimate. This is why we use Fibonacci. When you get to a task that you consider to be a 13 there is a lot of uncertainty and it is best to consider the 'next' level of effort to be 21 as that is about the level of accuracy you can practically use ahead of time.
Another real world example of how uncertainty increases further out in the future - whether you go shopping in 1 day or in 2 days is something you have a high degree of certainty about. If you are out of milk then there is a big difference between 1 more day and 2 more days! However, today, you don't know what your situation will be in a couple of weeks, right? So that's why it jumps from say 8 to 13 - somewhere in those 5 days you will need more milk again, but which specific day in that range you can't predict right now.
Fibonacci series is just one example for estimation efforts. Some teams also use series as below:
1, 2, 5, 8, 20, 40, 100, .... 1, 2, 4, 8, 16, 32, 64, ....
The idea is to use an exponential scale for estimating efforts.
The reason is the larger the story point, the more uncertainty there is around it and the less accurate the estimate will be.
Common estimating methods include numeric sizing as well like 1 to 10 or sizes like XS, S, M, L, XL, XXL, XXXL or Fibonacci sequence 1, 2, 3, 5, 8, 13, 21, 34, etc.
The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. A high estimate usually means that the story is not well understood in detail or should be broken down into multiple smaller stories. Smaller stories can be estimated in greater detail. It would be a waste of time to discuss if it is 19, 20 or 25 the story is simply too big.
Important is that the team shares a common understanding of the scale it uses so that every member of the team is comfortable with it.
Spoiler: No scientific reason.
Fibonacci grows very fast, so people will have fewer options before reaching enormous values; thus it incentivizes breaking work down in smaller pieces.
If the smallest typical work takes 1 hour, a big piece may take 8, 9, 10, ..., 16, ... even 32 hours.
However, if the smallest piece of work takes 1 story point, and they grow in Fibonacci, a big piece may take only either 8, or 13, or 21, and only if you stretch much 34 story point - 4 options to pick rather than 24.
Posted about this just recently. Reference to the original is at the bottom.
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. Etc.
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.
A notion I don't see in any of these answers is that in a simple 1-10 range, people can get bogged down in whether something is a 3 or is it really a 4? And what if another person thinks that it should be a 2 instead of a 3?
By using a Fibonacci sequence, you eliminate a bit of that "hair splitting".
This question is answered in a blog post by Jeff Sutherland (co-creator of Scrum). It's rooted in a US Department of Defense study on estimation.
Rand researchers then studied the effect of the numbers estimators can choose and found a linear sequence gave worse estimates than an exponentially increasing set of numbers. There are some recent mathematical arguments for this for those interested. The question then--if you want the statistically provable best estimate--is what exponentially increasing series to use. The Fibonacci is almost, but not quite exponential and has the advantage that it is the growth pattern seen in all organic systems. Why does the Fibonacci sequence repeat in nature?
I think the main reason is because it easier to estimate in relative sizes. This is smaller or larger compared to that. If you look at different buildings from a distance, you could say that one is twice as large, but getting the exact height correct is much harder. For Agile work this means, if that took 2 days, this other thing of similair complexity will take probably also take 2 days.
The second reason is that estimating in hours has the risk of not taking slack and uncertainties into account. Saying a batch of work takes 8 hours does not mean it will be finished in a single day. Probably it will take two days, because noone works effectively for 8 hours, but the project manager already sold the estimate to the client who expected it yesterday. The larger the estimate the higher the risks.
Now why use Fibonacci? The Fibonacci sequence is a natural size, most things in nature have these relative steps. So the brain is already used to these ratios, because they are everywhere. For example, the bones in your hands follow this pattern, but also leafs, shells, etc
II would like to ask that you genuinely try to answer/estimate every question I ask before reading on. The goal of this answer is exactly to make you understand how humans tend to estimate something when they don't know the exact answer. There's no better teacher than your own mind.
Which number is exactly between 1 and 9?
Most people will say 5, because 5 - 4 = 1 and 5 + 4 = 9.
Seems obvious, right? However, when you look at people who have not been "tainted" by a common education, i.e. children and remote tribesmen, you'll notice that they all agree that you're wrong.
Their reasoning is that 3 is in the middle between 1 and 9, since 3 / 3 = 1 and 3 x 3 = 9, which mirrors the reasoning for why we think it's 5, but it uses multiplication and division, instead of addition and subtraction.
Here's a much better explanation than I can give. But I will give you one example of this:
I'm going to introduce you to three people. A millionaire, a billionaire, and a trillionaire. If you think about their wealth, you'd intuitive say that the billionaire is sitting inbetween them, right?
Here's a fun fact: if you sum up the amount of money you need to give 1000 millionaires to make each of them a billionaire, and you instead decide to give this lump sum to the (original) billionaire, that would only just make them a trillionaire.
Knowing this, your interpretation of these numbers should shift, and it should become more intuitively understandably that these three numbers are not equidistant from one another.
If you're still not convinced, another way to think of it is like this:
Have a guess before you look it up. I'd put money on it that any genuine guess you make is going to be much too low.
* A trillion seconds is 316 centuries
Human are generally more capable of estimating value increases/decreases when expressed as a % of the initial value; which is effectively what a logarithmic scale does.
The billionaire who lost half a billion dollars on the stock market today, is going to be as upset as the millionaire who lost half a million dollars on the stock market. We think that it's equal because both numbers represent 50% of the original value, and therefore it's proportionally equal.
But when you look at the amounts of money by themselves, they are nowhere near equal. They are off by three orders of magnitude, which is effectively the same as you not distinguishing whether I bought $50 or $50,000 of groceries this morning.
This intuitive human behavior of thinking in logarithms lies at the root of why estimations are logarithmic (increasing exponentially) instead of linear (increasing by a constant step size).
We shouldn't forget why we call it an estimation: we spitball it because it is hard to get it exactly right. Development is not naturally intuitive, and predicting development accurately is one of the hardest parts about development. Giving humans a tool they innately understand (logarithmic scales) means that they can focus more on the thing they should be thinking about: projected development effort.
It doesn't have to be the Fibonacci series; any series with an exponential growth will do. But it's my intuitive guess that Fibonacci's exponential growth (i.e. the golden ratio) strikes a natural balance between too much and too little of an exponential growth.
Mike Cohn says in his book Agile Estimating and Planning that he originally used 1, 2, 3, 5, 8, 13, 21 as his sequence until a client said to him "You must be very confident to estimate the size as exactly 21 and not 20 or 25". He realised that 21 was too precise, so he changed it to the vaguer value 20.
8 is bigger than 5 and smaller than 13. It's much bigger than 3 and much smaller than 20. Some teams use other sequences such as doubling: 1, 2, 4, 8, 16, however, in my mind that makes it too precise. It seems to be claiming that a 16 is almost exactly twice as big as an 8. I prefer the vagueness of the modified Fibonacci sequence. If a task is twice as big as an 8, it's probably a 20 because we tend to underestimate rather than overestimate. It also allows for "about 50% bigger", so 50% bigger than 8 is 13, again slightly inflated.
I find that the Fibonacci sequence has the right balance between precision and vagueness. However, the Fibonacci sequence is just one sequence for estimating the size of each task. Obviously each team should use the values that work for it. If you find that some other sequence works better for your team, by all means, use it.