# Estimation values: near-Fibonacci vs. true Fibonacci

This excerpt from the Kindle pocket guide, Practical Estimation, discusses the relative merits of using the familiar “near Fibonacci” sequence vs. the true Fibonacci sequence for estimating work effort.

# Fibonacci Numbers

Estimates are educated guesses. They are predictions based on past information, therefore we cannot expect them to have a lot of precision. If I spend time agonizing over deciding whether a task is either, say, 50% or 51% larger than another task, I am probably wasting time. Any individual estimate, being an educated guess, is not going to be correct with that kind of precision. Sometimes an individual estimate will be too large and other times too small. We can, given a number of samples, expect these anomalies to cancel each other out over time, yielding fairly reliable predictability of schedule.

We can limit the amount of precision that our estimates imply by using numbers from sets that are not contiguous. The Fibonacci sequence is an example of one of those sets.

A number in the Fibonacci sequence is created by summing the prior two numbers. Starting with zero, the sequence is:

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

The extra “1″ is unnecessary, so we can ignore it. Likewise, some may find that the “0″ is superfluous.

The Fibonacci sequence is handy for several reasons:

• The formula to generate the sequence is easy to remember and perform.
• The gaps between numbers grow as the numbers get larger, and can be thought of as representing the “uncertainty” of an estimate.
• Throughout the sequence, the numbers grow at a rate that makes it possible to represent useful relationships such as (roughly) one-and-a-halftwicethree times larger, etc.

# Near-Fibonacci vs. True Fibonacci

Some teams use what might be called a near-Fibonacci sequence, which looks like:

1, 2, 3, 5, 8, 13, 20, 40, 100

Notice that this sequence differs from the true Fibonacci sequence after 13. Early on, when I first started practicing relative estimation, I was encouraged to use this “near” sequence, and to think of the smaller numbers (1-13) as being the proper sizes for work items. Anything larger than a 13 was assumed to need decomposition into smaller items.

But tying a specific range of numbers to a specific block of calendar time can have the unfortunate side effect of causing team members to mentally (and unconsciously) map individual estimates to absolute time. When that happens, estimates become little more than alternate representations of calendar time, an unnecessary complication. We might just as well have estimated in hours (which we’re not especially good at).

I like to use the true Fibonacci sequence because it allows expression of relationships between work items of all durations. Using numbers from this larger sequence enables quick, up-front estimation of entire projects, even when its components have not necessarily been broken down into work-sized items.

I also favor the true Fibonacci sequence for its re-scalability. If, for example, I initially estimate a work item as a “1″, then eventually encounter other work items that are smaller, I can re-label any existing work items so that my “1″ becomes a “13″ and then I have all of the smaller numbers (1,  2, 3, 5, 8) to work within. In other words, I can make all of my estimates consistent relative to each other, regardless of size, because there is no upper bound to the sequence.

Another way to think about this is to consider the idea that the following two sequences are roughly equivalent to each other:

1, 2, 3, 5, 8

13, 21, 34, 55, 89

If you’re doing relative estimation, since all you’re really interested in are the ratios of the numbers (and not the absolute values of the numbers), then you should be able to use the above two sequences interchangeably. For example 2:1 is roughly equal to 21:13; likewise 3:2 is roughly equivalent to 34:21 (given a level of precision that is appropriate for estimates).

See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

# Are you really doing relative estimation?

This excerpt from the Kindle pocket guide, Practical Estimation, discusses how estimating with abstract units does not necessarily mean that you are doing relative estimation.

As a software developer, I may not really know how long in absolute terms (e.g. hours, days) a particular piece of software will take to develop. If you are a software developer, it is likely that you have experienced this first-hand.

Manager: “How long is this project going to take?”
Developer: “Three months.”

That exchange is an example of absolute estimation. One person has asked for an estimate in terms of calendar time, and another has responded in kind. Nothing wrong with that, on the surface—it is perfectly natural for the developer to answer a question the way it was asked. A difficulty arises, however, if the developer doesn’t yet have sufficient information to answer the question, but answers it anyway just because it was asked.

Early on in my own career, I did software development work on a fixed-price contract basis. That could be a tough game because if I didn’t bid a contract appropriately, I ended up making less (sometimes a lot less) money for the time spent. Working as a programmer making minimum wage wasn’t a career goal, so I had a very good reason to get good at estimating.

Here’s the basic technique I used:

• Break down the work assigned into as many small tasks as I could think of
• Estimate each of those tasks, in hours
• Pad the sum of estimates by 50 to 100% to account for unforeseen work
• Present the estimate to my manager
• Resist my manager’s attempt to negotiate the estimate downward
• Do the work, which would take more time than either of us had imagined

I hoped that repeating the above process on each new contract would eventually help me get better at the estimation part, but it never really did, even though I was highly motivated. (Later on I overheard my manager telling someone that he usually took my estimates and doubled them in order to get an idea of schedule.)

I never really got good at this kind of direct, absolute estimation, and it wasn’t until many years later that I learned another way.

## Relative Estimation vs Absolute Estimation

Manager: “How long is this project going to take?”
Developer: “The project has been estimated at 720 points, and we’re currently averaging 60 points per week, so 12 weeks.”

That conversation is an example of the ultimate use of relative estimation. Even though the manager has asked for an estimate in terms of calendar (absolute) time, the developer has responded, at least initially, in terms of some different, abstract units called “points,” then performed a quick calculation to convert those points to something the manager can use.

The assumption here is that the project in question consists of a number of individual development tasks, that each of them has been assigned its own estimate (in points), and that those have been added together to arrive at a single estimate for the entire project.

Relative estimation also necessarily implies indirect estimation, meaning that estimates are expressed in some abstract units, such as the points described above. This doesn’t work both ways, however. Using abstract units does not necessarily mean that you are doing relative estimation. It’s entirely possible (and fairly common) for development teams to engage in what might be called indirect, absolute estimation. This occurs when point values are merely substituted for their absolute equivalents.

I’ve worked on and with several development teams that believed themselves to be practicing relative estimation, but who were actually performing indirect, absolute estimation. The telltale sign in every case was that team members mentally mapped point values to calendar values while estimating. The typical thought process was something like, “Well, I think this task will take a full day to complete, and 1 point equals half a day, so this task is 2 points.”

So it’s possible to estimate in abstract units while actually engaging in absolute estimation. This is not especially useful, in that it adds an unnecessary level of indirection to the estimation process, which is no better than estimating directly in absolute units (e.g. hours, days).

## Telltale Signs of Absolute Estimation

Relative estimation is always done using abstract units, so it’s easy to believe that, if you’re estimating in abstract units, you’re doing relative estimation. But units alone aren’t enough of an indicator—it’s entirely possible to estimate using abstract units (e.g. points) while still only doing absolute estimation.

Here are some ways to know if you’re just doing absolute estimation:

• Relative estimation relies on comparison, therefore it requires at least two items (task, features, etc.) to work properly. If you find yourself assigning point values to individual items, without comparing them to other items, then you’re probably engaging in indirect, absolute estimation.
• If, when you’re estimating, you find yourself thinking of point values as mapping to a specific amount of clock or calendar time (e.g. 1 point = 4 hours), you’re probably engaging in indirect, absolute estimation. At estimation time, estimates should be thought of as relative to each other, not mapped to clock or calendar time.
• If you find it necessary to introduce new values (such as “½”) into the Fibonacci sequence in order to make some estimates fit, you’re probably engaging in indirect, absolute estimation. The ”½” that is sometimes used in estimation sessions to indicate a small effort is a clear sign of mapping points to clock or calendar time. In true relative estimation, you can simply re-scale your estimates to make room for a smaller estimate.

See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.