Fibonacci Considered Harmful

On an Agile-related Facebook group recently, I saw this post from a Product Owner new to a team and after the initial shock wore off I felt that I had to write about it:

The debate about whether or not to assign points or any other estimate to diagnosing and fixing defects isn't the point here. What shocked me was the person stating that the team with which he worked had sprints with work totaling between 150 and 500 points!

I was... shocked. If he had said 15 to 50 then I wouldn't have batted an eye, but an order of magnitude higher? I couldn't understand how a team could possibly be pulling that much work into a sprint, let alone completing it. Then I realized that two personal biases were affecting my perception.

I learned about stories and estimating using points from the people who originated the concepts, and thus had the context of the problems they were solving using the techniques. So, my first bias was towards splitting stories down to the smallest possible slice that delivers tangible value. You can read about how I approach slicing stories in order to get some context around what I mean by thin and/or small.

My second bias follows the first quite closely. When I learned about using points to perform relative estimation, there were only 3 values "allowed": 1, 2, and 3. If anything was bigger than a 3, it needed to be split!

However, in Mike Cohn's 2004 book, User Stories Applied, he recommended using a scale of 1/2, 1, 2, 3, 5, 8, 13, 20, 40 and 80 (with 100 later substituting for 80). Although Mike didn't state it explicitly in the book, at some point someone recognized that this was almost like the Fibonacci series and thus was born the "modified Fibonacci" scale for story points. This opened up a whole new world of values when estimating stories, for better or for worse. To be fair, Mike suggested that the higher values would be used when estimating epics which would be later broken down into stories rather than for the stories themselves.

Mike also said that his scale was based on the assumption that 1 point was equal to 1 "ideal" day, meaning a day that had no interruptions and allowed complete focus on work. Again, the originators of story points most definitely did not have that in mind when they came up with the concept! In fact, story points were created in order to avoid time-based estimates and were supposed to be relative measures of effort between stories. This was the fundamental reason why points were not transferable between teams - one team's 2 points could be another's 3, and yet another's 1! Coupling a point with an ideal day had the effect of making it a universal measure rather than a simple approach within a team to be used for planning an iteration.

While User Stories Applied is otherwise a great book, these two aspects - modified Fibonacci and 1 point = 1 ideal day - have resulted in a tremendous level of pain & suffering among teams new to Agile.

In my work as a coach, it hasn't been unusual to encounter stories at the higher end of the scale, or to see everything lumped into the middle as a 5, 8 or 13.

In the latter case, there really isn't much point then to using Fibonacci, is there? Instead, a team could just substitute 1 for 5, 2 for 8 and 3 for what they thought was a 13 and the effect would be the same. I've advised that before, but it generally fell on deaf ears. More on why in a moment.

Fibonacci applies what appears to be mathematical certainty - a sequence - to something that is anything but certain - an estimate in software development

The former case, though, is more interesting. After reflection, this is what I believe was happening in the case of the team pulling 150 to 500 points of work into a sprint. It's quite likely that every bit of work had an estimate in the 20, 40 or 100 range. I suppose it's also possible that they simply equated points to hours, but we'll stay with the original premise for the time being.

This is my biggest complaint about using the "modified Fibonacci" values for estimating. It applies what appears to be mathematical certainty - a sequence - to something that is anything but certain - an estimate in software development.

My other complaint, to which I alluded above, is that by having so many values from which to choose, it enables teams to forego splitting stories and work in larger batches than they otherwise would if limited to only 3 possible values for a story. While story splitting is rather different from the functional decomposition that teams have traditionally used, it's a relatively easy skill to learn. There are numerous resources available to help with the technique, including User Stories Applied!

Additionally, the larger values in the modified Fibonacci scale were intended from the start to be used with epics, which are a larger form of stories that haven't yet been broken down. I still see, though, estimates of 13, 20 & 40 applied to individual stories that are to be pulled into a sprint. And this is what I believe happened in the case of the team I mentioned at the beginning. Note that the Product Owner says that the group isn't delivering. I'm willing to bet that the stories with the large estimates turned out to be even larger than they thought! That results from a very simple issue - the larger the individual piece of work, the more uncertainty it contains!

To address these issues, I recommend first learning how to effectively split stories. You can start with the Agile Alliance glossary page on the topic, which has links to several excellent articles and resources. It would also be helpful to read some of the original material about user stories to better understand the original intentions behind them. For that I recommend, Extreme Programming Explained, 1st Edition and Extreme Programming Installed, plus this classic blog post from Ron Jeffries called, A Metric Leading to Agility.

If you're able to break stories into much smaller pieces, then there's less for the team to discuss with the Product Owner, less development that needs to be done and less testing required. Each story then flows much more smoothly through the team's process and the completion rate climbs significantly. This also allows you to abandon the modified Fibonacci scale and its flaws altogether. You can either limit the allowable estimates to 1, 2 and 3 points, or simply dispense with points altogether and just count the number of stories completed in an iteration. After all, the metric these are used with - velocity - is simply intended to provide a means for a team to decide how much work to pull into a sprint.

My opinion that modified Fibonacci is harmful may not be popular, but I've seen far too many groups needlessly struggle because of it. I suspect that many of them don't even know that there are alternatives, but there indeed are!

Oh, and to answer the PO's original question about estimating bugs? Don't do it!!