Why do we use Fibonacci series for estimation ?

Hello All,

I would like to know the advantages /disadvantages of using Fibonacci series for estimation.

Your inputs are really appreciated.

Thanks !

Pratibha

What are your own thoughts about this? What is it about the Fibonacci series that makes it useful for estimation purposes?

i think using T-shirt size or just a normal sequence 1,2,3 or any even/odd series should be giving the right estimation if team has good technical and functional skills...but don't understand why most of people says follow fibonacci...

is it just like following majority?

With a Fibonacci sequence, the gaps gradually increase between the values, e.g. 1, 2, 3, 5, 8, 13. Can you see how this might facilitate estimation?

It's hard to change the mindset. It feels so normal to use time as estimation and with this in mind Fibonacci sequence doesn't make any sense. However, if you look at the number as overall complexity for a team of 5...

Estimation and groomings as a whole are the most important pillars. And also tough to handle. I'm not a scrum master, just a PO, but I have my experience with it. I summed it up in here if you are interested:

http://www.kentico.com/blog/story-points-generator-oh-for-the-love-of-g…

I would appreciate if you can help me understand how this gradual increase is most helpful while estimating the user stories.

Thats what I need to understand the advantage and disadvantage of using Fibonacci series...

Your inputs would be very helpful

Michal is on to something when he says the "Fibonacci sequence doesn't make sense."  It's not something you're used to working with, and it forces you to think about what the number is and how it compares to other numbers.  If I tell you one story is an 8, and another is a 4, you would clearly identify the second task as taking almost exactly half as long as the first one.  Fibonacci forces you to rethink this because there is no 4.  Your choices are 3 and 5.  So is it more than half, or less than half?  Not as easy to decide, is it?

And the mathematical beauty is that it will never be half.  Half of 13 is 6.5, which is exactly the same distance from both 5 and 8.  Half of 34 is 17, which is equidistant from both 13 and 21.  This pattern continues throughout the sequence.  If you ever want to say something is "half as many points," you can't.  Fibonacci always requires that you decide if something is more than half, or less than half.  That's the point.

> I would appreciate if you can help me understand how this

> gradual increase is most helpful while estimating the user stories

How useful do you think most people would find it, when estimating, to assert that something is (say) 39 points, or 40, or 41? Is such precision likely to be realistic, when compared to estimating small work items of 1, 2, or 3 points in size?

Hi Ian,

I would like to try to answer your question: 'How useful do you think most people would find it, when estimating, to assert that something is (say) 39 points, or 40, or 41? Is such precision likely to be realistic, when compared to estimating small work items of 1, 2, or 3 points in size?'.

My interpretation of the Fibonacci sequence has always been that as the uncertainty and complexity of the task at hand increase, so does the figure resulting from the sequence. The points increase significantly relative to an increase in complexity and uncertainty.

This means that when we assign a low amount of points to a task, we are more certain of the context, difficulties and attributes of that task than when we assign a high number. In your example, assigning in the range of 40+ points means to me that the task at hand is considered to be so large as to making any accurate approximation of that task impossible. T-shirt sizes might be the better choice in this situation. Tasks in that range should be refined to more comprehensible sizes in my opinion.

Hope this helps,

James

Hi everyone,

I agree with what everyone said.

I have the same interpretation as James - having a complex User Story takes into consideration the uncertainty and factors that are not taken into consideration that are far more understood in something that is estimated a lower number.

In my experience, it also prevents a false sense of confidence. If you are unsure of what needs to be done, would you bravely give an exact number to present your effort, or do you want to throw a number that could be less accurate to compensate for factors that aren't accounted for in a User Story? Would you rather be roughly right or precisely wrong?

Let's say you have a User Story A, effort of 1, and a more complicated User Story B. If we estimated it as a 4, that would probably equate to taking 4 times the amount of work to finish compared to A. Could B be broken down to bits of work that make it similar to A? Probably not, and what if B was broken into B1-B4, should B1-B3 reach "done" and B4 didn't make it, what are the chances that the result is a potentially releasable?

Fibonacci, paired with User Stories being high-level estimations, gives a more approximate idea (educated guess) of how complex a feature is going to be. In the previous case, B could be a 3 or 5 and there's a clearer idea of how complicated it can be to develop compared to A. In this same case, an effort of 3 or 5 still sounds like a User Story that is standalone and a fully-functional piece of a software on release. You will also see later on that not all 3's, 5's, 8's or 13's take the same length to finish, but they still purvey complexity assumed with those numbers.

With Empiricism in mind, you can also use Fibonacci as a means of gauging how an estimated effort translates to work (man hours) in a Sprint. For instance, if you run a 2-week Sprint and have noticed a trend that 5-effort is 2.5 days, 8 is close to 4 days and 13 could be a little more than half the Sprint, then it's possible a 20-effort is a whole sprint to finish or more. This tells us that while a lone 20 could be delivered in a Sprint, it's way too complex, and it's possible to break the User Story into four 5-efforts or an 8 and 13. User Story becomes more defined because of the break down, and you still churn out a working piece of the software.

I guess a disadvantage of using Fibonacci is because of how the gap changes between numbers, any number over 1 could easily be under or overestimated. I recall in my previous run as Scrum Master in my company, we had instances where (a) a User Story felt like it was somewhere between an 5 or 8, or (b) an 8 would either turn out to be a 13 or a 5 as the Sprint progressed. To air on the side of caution, we always used the larger number.

At the end of the day (in the realm of Scrum), proximity is far better than precision.

For me, using Fibonnaci sequence is not the same as estimating in Story Point.

You can actually estime everything with the Fibonnaci sequence, (time ; weight ; effort ; distance ; size ; speed...). The unit is not an issue.

The point is to lead people to use relative estimates instead of absolute estimates, just because human brain is very poor with absolute estimates and good enough with relative estimates.

Pratibha - You may like to see my blog on LinkedIn at the below URL which should answer your question. Thanks and Regards, Vijay 

https://www.linkedin.com/pulse/simplicity-relative-estimates-modified-fibonacci-series-vijay-kharade

I believe that most of the discussions here covered almost all the possible reasons of the benefits of using Fibonnaci sequence, here is my understanding:

1. Flexibility vs. precision (Facilitates consensus rather than decimal precision)

2. Progressive range expansion vs. Steady range (Relative Size and priority levels calls for such an approach)

3. Balanced view focusing the proper attention on the User Stories which are on the top of the Product Backlog receive the proper amount of attention as Scrum team prepares for the upcoming Sprint. While the other items of lower priority and those on the bottom - such as Epics - are simply estimated.

The benefits are clear as all these allow us to make decisions iteratively while deferring, re-estimating, desegregating as we learn more by frequently delivering increments and collecting feedback.

The point is to lead people to use relative estimates instead of absolute estimates, just because human brain is very poor with absolute estimates and good enough with relative estimates.

- Olivier Ledru

Yep! 

I think the most important objective is the entire team having an understanding of what the size means.  If a team can use shapes or symbols to estimate and the PO is able to understand what that means and convey that to stakeholders then use shapes and symbols! 

The bigger the task, the more uncertain it is how much effort is required to do it, so gaps between points should reflect that. However I am not fan of fibonacci, as those numbers are not easy to do math. 5 to 3 is something like 2/5th more, that is... how much more complex it really is? Crucial is that estimate of 2 will take twice as long as two tasks with 1. Crucial is that math does work with estimates so you can sum them up.