Fibonacci Must Die!

Leonardo Fibonacci died over 760 years ago but he had a profound effect on mathematics in western civilization.  He brought what he had learned from mathematician in north Africa back to Europe and authored the book Liber Abaci, which described such things as the Hindu-Arabic numeral system and place value of numbers.  In the book he also showed how a number of mathematical problems were solved using the techniques he had learned, one of which was the growth of a population of rabbits.  Although he didn't invent it, that sequence bears his name today, and is seen in many places in nature.

The use of the Fibonacci sequence in a slightly modified form has also been popularized in the Agile community as values which can be used to estimate the effort required to deliver work.  This is usually tied to the Planning Poker technique created in 2002 by James Grenning, and Mike Cohn's Mountain Goat Software sells decks of planning poker cards that use the values 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and infinity.

If you look, though, at James' paper and Mike's excellent 2005 book Agile Estimating and Planning, they both make a very similar point.  From James:

As the estimates get longer, the precision goes down. There are cards for 1,2,3,5,7,10 days and infinity. This deck might help you keep your story size under 2 weeks. Its common experience that story estimates longer than 2 weeks often go over budget. If a story is longer than 2 weeks, play the infinity card and make the customer split the story.

From Mike's Agile Estimating and Planning (pg. 52):

Because we are best within a single order of magnitude, we would like to have most of our estimated in such a range.  Two estimation scales I've had good success with are:

• 1, 2, 3, 5 and 8 [Fibonacci] 
• 1, 2, 4 and 8

In both of these cases, James and Mike recognize that as estimate size increases accuracy decreases rapidly, and they both use a very narrow range of values that can be used for estimates.

Why is that?  Well, I'm going to borrow a famous acronym from the Extreme Programming world: YAGNI... You Ain't Gonna Need It!

Yes, Mike's card decks have many more values.  I suppose that a deck with 5 values and infinity would be somewhat less attractive to buy, but the real point is how much damage is being caused by teams using values of 13, 20, 40 and 100?  Do those numbers really mean anything?

I assert that they are meaningless, and actually cause much more harm than good.  The harm comes from 2 sources.  First, it allows teams to get away with not splitting work down into pieces that can be estimated reliably.  Second, and as a consequence of the first, by providing inaccurate estimates for very large things teams/product owners/stakeholders can have a false sense of security about how much effort will be required.  Estimates that are wildly inaccurate will lead to incorrect decisions about whether to proceed with some work or not.  The smaller the piece of work being estimated, the higher the probability that the estimate is accurate enough to make reasonable decisions.

The Curse of Choice
Having too many choices is actually a curse, and limiting the choices available for teams to use for estimation forces them to really think hard about breaking the work down.  I personally have used the four values of 1, 2, 3 and "too big" with good success over the years, but I can certainly live with what James and Mike suggest above.

To go a step further, though, we should be applying Lean thinking and strive to eliminate the variability of the size of work completely.  This would mean that all items are broken down until they're the same size, obviating the need for any estimation at all!  That's a perfection vision that very few people have achieved, although it has happened.

In the end, we need to move away from using the longer modified Fibonacci series as if it were a law of nature.  Being modified, it really isn't a law, and actually provides very little value beyond the number 8.

Within Agile teams, Fibonacci must die!