Fibonacci Must Die!

This content is syndicated from Practical Agility by Dave Rooney. To view the original post in full, click here.

Leonardo Fibonacci died over 760 years ago but he had a profound effect on mathematics in western civilization.  He brought what he had learned from mathematician in north Africa back to Europe and authored the book Liber Abaci, which described such things as the Hindu-Arabic numeral system and place value of numbers.  In the book he also showed how a number of mathematical problems were solved

3 Responses to “Fibonacci Must Die!”

  1. Kelly Waters says:

    Hi Dave. I read your post with interest. As you said, Fibonacci died a long time ago! :)

    Personally I really like Fibonacci numbers for estimating. I love the fact that the numbers get increasingly less accurate as the estimates get bigger. That just makes sense to me.

    But I agree with you that the range needn’t be that big. Remembering that the estimates are meant to be relative to each other – in other words a 3 is meant to be 3 times the size of a 1 – even just using 1, 2 and 3 is a pretty big range as it is, since work is meant to be broken down into small pieces.

    I think I agree with all your points except the headline and the last point that Fibonacci must die in agile teams. Instead I think it’s very useful, but the number range should be severely limited, perhaps to 1, 2, 3, 5, too big. How can we really talk about something that is 13 times bigger than something else. It’s hard to do that with any degree of accuracy.

    I also quite like the variation of 1, 2, 4, 8. Obviously this isn’t Fibonacci but does have an exponential shape to it which has the same positive effect on estimating accuracy as Fibonacci.


  2. Chris Davies says:

    I disagree, I’m afraid and for one reason only – project or Release planning.

    I have found it useful to estimate stories in the 13, 20 and 40 point range purely to understand the total story point count. Dividing velocity into this number gives the number of timeboxed iterations needed.
    Yes, if all stories were the same size we wouldn’t need to estimate at all and in some environments (ongoing product development as opposed to new projects) that is the ideal. Most of our projects, however, are of 4 – 9 month duration and we need to understand the full scope and whether we have a chance of delivering it. In this environment, it is impractical – and unnecessary – to break down all stories to the 1 – 3 point range up front.

    I am encouraging teams to break the story down to 5 points or less when planning each timebox. Until then, they can stay larger than that.

  3. Kelly Waters says:

    That’s a fair point Chris, if you are estimating an entire product backlog in points at the start of a big project, you may well have epics just as placeholders and they may well be larger until it’s time to break them down into smaller stories…


Leave a Reply

What is 7 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)