Cult Of Fibonacci

Scrum was supposed to help team start with the simplest thing that could possibly work. And then add complexity only as proven needed for their situation.

Let’s take estimation. Everywhere I go, teams are using a wide range of Fibonacci numbers such as 1, 2, 3, 5, 8, 13 … on until ridiculously high numbers). Some teams may really need a large range of Fibonacci numbers. But the fact that nearly all are using this shows we trainers and coaches have failed to teach teams to experiment with their own methods. Ken Schwaber’s central message was that self-organizing teams must own their methods and processes, rather than copy methodologists.

Today there are more “Scrum teams” using Fibonacci numbers than there are doing Scrum.

Trainers often give out decks of cards way more numbers than I’d encourage anyone to start out with. I have even heard trainers claim that we should use the Fibonacci sequence because of “science.” A few years from now we’ll all wonder why we bought into this fad.

Despite what you may have been taught, Fibonacci numbers do not have magical powers. Apart from the pseudoscientific mysticism, their only point is that they increase roughly exponentially. But so do powers of 2. Powers of 2 are far simpler than Fibonacci numbers. People who know binary recognize them as round numbers, perhaps avoiding the illusion of precision that Fibonacci numbers seem to cause.

A team that starts with the simplest thing and adds complexity only as proven needed might also try:

• #NoEstimates, or
• very simple estimates (e.g. Small vs. Not Small), or
• a simple range such as 1, 2, 4, TOO BIG, or
• using only a small subset of the Fibonacci scale. Throw away most of the cards!

From a development team perspective, the only estimate that matters is whether an item will fit into a Sprint or not. Anything bigger than 1/4 of a Sprint is too big.

For others, such as the Product Owner and the “Are we there yet?” stakeholders, estimates might help provide forecasts about when particular Product Backlog Items will be done in future Sprints. Here’s why I say might: In software development, the evidence supporting the claim that more estimation time improves accuracy is very weak. Years ago, Mike Cohn sent me experiments where changing the font size of the requirements document would change the estimate. In other experiments, more estimation time reduced the accuracy of the forecast! Some organizations say they just count their items and get forecasts that weren’t any worse than the ones they got with lots of estimation time.

Being Agile is about being adaptable, including changing the requirements. There is no “project.” We want to be able to change business directions as we learn more about customer needs. Terry’s Agility Index, emphasizes that the Product Backlog should change every Sprint. In an emergent space, every plan is wrong by definition. Scrum teams strive to keep the product shippable at all times. I’ve noticed that companies that can deliver continuously don’t worry about estimates very much.

• Q. I noticed on Twitter and LinkedIn that you don’t like story points…
• A. I do like story points. And planning poker. In this example the team uses four cards only, with simple powers of 2.

• Q. Why are you making a big deal over this? It’s not a problem if one team decides to use Fibonacci numbers.
• A. Agree that’s not a problem. But when so many teams “decide” to use them, it’s an indicator we haven’t taught them to think for themselves.

See also: Fibonacci must die