Fibonacci estimates

The meeting where everything’s made up and the points don’t matter

In Agile™️ software development, it’s common to give a Fibonacci estimate for a task. Exactly what a developer is supposed to be estimating is a subject of debate. In theory, it’s supposed to be estimating how difficult a task will be in relation to other tasks. In practice, many project managers use these estimates as a substitute for time. This substitution is foolish and counter-productive.

Any time I see somebody mistreating Fibonacci estimates, it reminds me of Goodhart’s law:

When a measure becomes a target, it ceases to be a good measure

The Fibonacci series

An unending sequence of numbers where each term is defined as the sum of its two predecessors

Named for an Itallian mathemetician credited with introducing the series to Europe, the Fibonacci series is an important mathematical concept. The Wikipedia article is a fantastic resource if you’d like to learn more about its history and relevance. The most important thing to know about the Fibonacci numbers for the purpose of this article is how the numbers get farther and farther apart as you go further into the series:

1, 1, 2, 3, 5, 8, 13, 21, 34, …

What are Fibonacci estimates

Fibonacci estimates, as the name suggests, are estimates based around a scale represented by the Fibonacci series. This scale is not a unit of measurement – it is relative. That means that if a Task B is more difficult than Task A, Task B gets a higher number than Task A. That’s all. Fairly straightforward.

Also straightforward is the reason this scale is used. The more difficult a task is, the less likely you are to be able to accurately estimate the difficulty. Therefore, as you go further up the scale, the less precision there is by the nature of what you’re trying to accomplish. A task that is assigned 34 points may not really be 34 points of difficulty – it may only be 30, or 27. But there is no number on the Fibonacci scale between 21 and 34, but it’s more difficult than another task that was estimated at 21 points. So there’s no debate to be had - it’s more difficult, so it gets the next highest point value.

Ultimately, Fibonacci points are like points on Whose Line Is It, Anyway? They’re made up, and they really don’t matter.

What Fibonacci estimates are not

I’ve seen far too many Project Managers that use Fibonacci estimates as a substitute way to guage how long something will take, or to “fill” a dev team time.

Last week, we got 50 points done as a team. Let’s schedule 50 points again this week.

- Somebody causing a problem

Even worse is trying to ensure every developer has enough “points” to keep them busy over a particular timeblock.

Last week, we got 50 points done as a team, and we’ve got 5 people. Everyone gets 10 points worth of tasks this week.

- Somebody causing a BIG problem

This completely ignores why the Fibonacci scale is used in the first place - it’s imprecise by design. It’s only good as an overall metric, it’s useless as a planning target. The more you zoom in, the less useful it becomes. Trying to get accurate estimates out of it completely negates the entire purpose.

I get that people in management want to know how long something will take. I want to know, too. But software often doesn’t work that way, and the Fibonacci scale is used specifically to address this.