I got an email today asking essentially, “WTF does Fibonacci have to do with estimating?”. Well, my argument starts with the word “estimating” as to me, it’s more about “sizing”.

The Fibonacci sequence is essentially a relative scale of effort required to complete a task.  It’s not meant to be an absolute value of how long something will take – rather, Task A is a lot harder than Task B, but twice as easy as Task C.  The smaller the numbers, the more accurate the sizing should be.  So if I know how to do a series of tasks because I’ve done them over-and-over, then I can baseline those as a “1” or a “2”.  Every task after that becomes a factor relative to that baseline and is based on how much you don’t know about a requirement (or feature) in addition to how much “you know that you don’t know”.

The Fibonacci scale is good for two reasons (and I’m leaving out the obvious “because Fibonacci sounds cool”) each of which addresses a different estimating concern:

1. I know how to do it, so the scale becomes relative to how difficult a task is, or
2. I don’t know how to do it very well so the scale is a measure of how much I don’t know.

In my head, I break it down this way.  Other people’s definitions may vary, but the scale should be roughly the same:

• 0: No effort required.  Or, there is some effort required (possibly not trivial), but there is no value delivered so no credit is given for doing the work. It’s essentially a chore that has to be done.
• .5: I’m a Fibonacci purist that likes to split hairs (the two “1″s in the 0,1,1,2,3… sequence are redundant so some people put a .5 in place of a “1″).  Or, since 0 is reserved for chores that provide no business value, I can use this in place of “No Effort Required”.
• 1: Trivial.  This will be an easy point for my burn-down chart.  I can do these all day to pad my stats.  Or, I underestimate everything I do because I assume I understand the requirement.
• 2: A little bit of thought is required, but I’ve done so many, I won’t even break a sweat.  Or, it sounds trivial, but I’m going to hedge my bets a bit.
• 3: I’ve done this a lot, I know what needs to be done, maybe a few extra steps, but that’s it.  Doubtful that I’ll need to Google anything. Or, hmmm.  I don’t want to overestimate or underestimate, so I’ll stick this one in the middle.
• 5: OK, now we’re getting into the heart of the problem.  Or, I don’t do this very often. I’ll need a fair amount of assistance from Google.
• 8: This is going to take some time and planning. Or, I’ve seen other people do this and I prototyped something like it a few years ago.  I’ll need to buy a book.
• 13: Possibly the maximum amount I can do and still get it done in one iteration or sprint.  If this item is truly reduced to its simplest form, then it’s a complex piece of work and depending upon my iterative velocity, I may or may not be able to get it done in the time required.  For example, if my average velocity for an iteration is “10” or “11” points, then this one task will be a struggle.  If my personal velocity is “16”, then I should be able to get it done, but there’s obviously a lot of unknowns associated with it otherwise it wouldn’t have been given such a high number.  Keep in mind that 13×1 != 1×13.
• 21: I don’t want to do it.  This is designed to show people that it is very complex and cannot possibly be done in the timeframe of an iteration or sprint.  Either the requirements are so fuzzy that it’s rife with danger, or someone keeps asking for something stupid and I want them to go away. Some people put their “21” at “34” or some other higher value.  Some make it an even “100” just to give it some distance from the standard sizing numbers.

One reason why this approach is used in Agile is because for absolute estimating, you need to tie the estimate to the actual person doing the work in order for it to be accurate.  Something that takes you 8h to do may take me 16h, but on a relative scale they can both be the same point value.  The nice thing is, that no matter what, the scale is the same for everybody.  Your “1 Point” and my “1 Point” may be different in regards to how long we each take to execute the task, but the since the scale is relative to our own individual abilities, I should see the same work completed curve as we both work through tasks with the same point values.

For team estimations, there is a nominalization process that occurs to make sure we’re all making the same assumptions behind our sizing.  For example, if I size a task at a “2”, but you throw down an “8”, given we share a similar amount of ability, we obviously are interpreting the requirement differently, or approaching it from different directions.  We get together and hash it out so that the actual sizing estimate is agreed upon.

You can also use the same scale for assigning priorities to the tasks so that it becomes easier to know what to jettison based on time constraints and also for measuring business value for help in prioritization.  The principles are the same.  The lower the number the higher the priority or the more definitive the expected value.  The higher the number, the more a priority is a “nice-to-have” or the more nebulous the value proposition.