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:
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.
More from: Agile Development
- Pair Programming – A Comprehensive Guide To Get You Going
- Why The Idea Of Test Driven Development (TDD) Royally Upsets Me
- 12 Basic Principles That Underlie The Agile Manifesto With Text From Original Manifesto
- 12 Practices That Make Up Extreme Programming In Agile Software Development Methodology
- 15 Agile Best Practices – Are you following these in your team?
- What is the format for writing an agile story card?
- How the Agile Teams and Organizations Mature and Become Fluent
- N-Things You Can Do With Continuous Integration Tools Hudson and Jenkins
- List of some popular agile methodologies of software development practices
- The chicken and pig cartoon for Agile Project Management – high resolution version recreated
- Why is Fibonacci series numbers used in Agile Planning and Estimations?
- What Makes An Agile Story Good? It’s the INVESTment.
- Roles and Responsibilities of Business Product Owner in Agile Teams
- 100 Plus Agile Terms – A Comprehensive List
- 15 plus best practices for continuous integration of your software
- Iterative development benefits in the Agile software development