Better Estimating Through Fibonacci Numbers
Sharing Our Expertise

Our consultants solve challenging business problems and love sharing their knowledge. Tap into our insights and put them to work for you.

Back to Blogs >>

Published by , on Wednesday, December 26, 2018

Much has been written about Agile software development for engineers. In these occasional posts, I discuss Agile from the perspective of a business manager and require no previous knowledge from my readers. My goal is to spread the virtues of Agile while allowing developers and executives to imagine their shared issues from the others’ viewpoint.


In a previous post, I explained story points using the example of the New York Times crossword puzzle. In that example, each day’s successively more difficult puzzle received a complexity score one greater than the day before. In this post, I want to expand that idea and introduce the superior concept of non-sequential story-point scoring.


The idea behind story points is that a project segment – described as a user story - with a higher point score, is more complicated and will require more effort than a project segment with a lower point score. It’s pretty simple on the surface, but sometimes falls apart when estimating user stories of similar complexity.


For example, one estimator may believe a user story deserves a complexity score of 4, where his counterpart views it as a 5. Mathematics and democracy suggest many ways of splitting those hairs, but the solutions lead to lots of clustered scores that may or may not represent a true differentiation.


For this reason, very smart people struck upon the idea of estimating story points using numbers which come from the Fibonacci sequence: a series of integers starting with 0,1… where each successive number is the sum of the preceding two.


0, 1, 1 , 2 , 3 , 5 , 8 , 13 , 21 , 34 , 55 , 89 , 144 , …


Agile and Fibonocci Numbers


As a result, the numbers grow quickly making the incremental difference between any two of them obvious. Estimators can feel the difference between a 5 and an 8 where the difference between a 4 and a 5 seems academic. Subsequently, the estimators tend to arrive at the same scores implicitly. In the example above, our estimators may have been in disagreement when the choices were 4 and 5, but when the choices are 5 and 8, they are both likely to agree, “yeah, that is closer to a 5.”


Wait, are you telling me that people implicitly agree on the difference between a Fibonacci scores of 34 and a score of 55?


Of course not! Even though there is a big numeric difference between 34 and 55 (19 to be exact), the difference between an 8 degree of complexity (34) and a 9 degree of complexity (54) is less clear. For this reason, it is unlikely that story point scores this high would have any real value.


This result leads us to another advantage of using Fibonacci numbers as story point scores. Useful ones are easy to understand, and big ones are just meaninglessly big. As a result, there is a natural incentive to lead requirement gatherers to simplify their user stories so that they fit small Fibonacci numbers. And projects of many small chunks are easier to understand than those of few large chunks.


Teams understand the relative complexity of a Fibonacci score up to about 8, but any story scoring higher than 8 becomes a head-scratcher and suggests that questions remain unanswered. In general, these user stories are best sent back to the requirements gatherer with a request for simplification. Agile teams know that even though there is a huge difference between a score of 8 and a 13, there is likely no practical difference between 34 and 55. That may seem strange, but teams get the feel for it after a while.


But just because small point differentials are visceral and large ones are meaningless, doesn’t mean there is never disagreement. These situations call for a game called Estimation Poker and underscore another benefit of low-value Fibonacci’s. The basic story point scores, 1, 2, 3, 5, 8, and 13, can all be represented with a deck of regular old playing cards where the King or the Queen is the 13. A delightful side effect is that estimation poker is fun to play, and following this discussion, I will postscript the rules.


Now that we have effort scores attached to bite-sized tasks, the team’s velocity can be easily measured. It turns out that over time, this velocity proves to be very consistent. A team facing a 100-story point task and knocking out 10 story points a week can reliably expect to complete the task in 10 weeks. This kind of predictability represents the holy grail of project management.


So, in addition to being cool and fun, Fibonacci numbers facilitate countable, small-effort user stories of measurable effort that lead to project management with very reliable and expected completion dates and budgets. Furthermore, additional requirements for this consistency, deconstructing overly complex user stories, and measuring velocity are inherent in the Agile framework. These benefits – and many others – underscore why Agile is simply more effective at predicting desired outcomes than any other project management methodology.




Post script: Estimation Poker

Here is how Estimation poker is played. The person responsible for the requirements reads the user story. Each of the estimators (likely the developers), gives it a score and discreetly selects a playing card from the deck representing that number (1, 2, 3, 5, 8, or 13). All estimators then expose their card displaying their score. If the numbers differ, all are given a chance to share their concerns. It is likely that discrepancies between scores are the result of some members of the team knowing something that the others don’t. Once that information is vetted, the game is played again. Eventually, a score is agreed upon and is either placed in the queue (the backlog) or sent back to the individual responsible for requirements gathering for additional clarification – and ultimately a lower score.

Categories: Agile,Agile Scrum,Scrum,Project Management

Original Post:

Recommended For You
Here in Agile Scrum-Part 2, I’m going to talk about the team. Who is included, and who isn’t. And why that’s important.
View More ...
If you just cringed when you saw this was about Agile, you're doing it wrong.
View More ...
Executives don't want to be told they have to learn something new. Lead your stakeholders to Agile using concepts they already understand.
View More ...
As a consultant, selling Agile can be a tricky business. To many executives, “Agile” smells like time and materials, yet it can help deliver exac...
View More ...
When working on agile projects, PSC recommends using Azure DevOps as the management tool of choice and building, testing, and deploying SharePoin...
View More ...
Much has been written about Agile software development for engineers. In these occasional posts, I discuss Agile from the perspective of a busine...
View More ...