Why is the Fibonacci series used in agile planning poker

Question

When estimating the relative size of user stories in agile software development the members of the team are supposed to estimate the size of a user story as being 1, 2, 3, 5, 8, 13, ... . So the estimated values should resemble the Fibonacci series. But I wonder, why?

The description on Wikipedia holds the mysterious sentence:

The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items.

But why should there be inherent uncertainty in larger items? Isn't the uncertainty higher, if we make fewer measurement, meaning if fewer people estimate the same story? And even if the uncertainty is higher in larger stories, why does that imply the use of the Fibonacci sequence? Is there a mathematical or statistical reason for it? Otherwise using the Fibonacci series for estimation feels like CargoCult science to me.

Answer 1

What is the significance of the Fibonacci sequence in Agile?
The Fibonacci sequence can be found in a variety of fields as well as in nature. It's been used to describe plant growth, estimate population expansions over time, simulate virus outbreaks, and anticipate financial market behaviour, among other things.

But how does this huge list of statistics relate to Agile planning?

The Agile Fibonacci scale, in essence, allows teams a more realistic way to approach story point estimates. The amount, complexity, and effort required to complete or implement a user story are represented by story points. The Fibonacci scale is used to assign a number to each story point. The greater the number, the more complicated the plot point is, and the more effort it will take to finish it.

As previously stated, estimates are frequently wrong due to people's tendency to be excessively optimistic.

Instead of basing an estimate on a similar project we performed previously, we believe we can accomplish it faster since we are more experienced and confident.The Agile Fibonacci Scale is exponential rather than linear, which allows teams to be more realistic while tackling larger, more complicated jobs.