Let’s start with a refresher for Fibonacci numbers. By definition, the first two numbers in the Fibonacci sequence are 0 and 1 (alternatively, 1 and 1), and each subsequent number is the sum of the previous two. Thus a Fibonacci sequence looks like:
0,1,1,2,3,5,8,13,21,34,55,89,144…
If you have worked in any Agile teams, you might have well noticed that the project estimations are not done in terms of hours. I personally believe this is a great thing for developers and testers (generally the time taken by the requirement analysts is not estimated or added to a user story estimation because the requirement work is assumed to have been already done when the user story is written) as they dont have to worry about the time factor when working on any piece of work. They can rather focus on the work itself.
Most of the Agile Teams that I have come across estimate their work in Tee Shirt Sizes (especially at Feature or Epic level) and do a relative sizing in Fibonacci Numbers at the User Story level. But have you ever wondered why Fibonacci numbers? Why not just plain 1,2,3,4… numbers? Well, there is a reason for that.
The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items. What this means is the larger the size of the card, the more uncertainty exist around what needs to be done to call the card “done-done”. Some people have noted that the Fibonacci sequence grows about the same rate at which we humans can perceive meaningful changes in magnitude, which could be another reason. By principle the larger stories can be sliced into smaller ones if possible. But it is not always possible to slice the work to provide business values. So, in keeping a user story larger, we introduce chances for uncertainty. It’s not possible to accurately estimate work that take days versus hours without introducing uncertainty. So by doing a Fibonacci sequencing for numbers, we account for such uncertainties.
Remember, the estimation is best if it is done as a relative sizing. This means, instead of estimating a card by itself, it is advised that we compare the card relative to other cards (either already done in prior iterations or the ones already estimated) and come to a point.
Originally posted 2012-12-17 17:56:18.
