# Is there a reason to use specifically fibonacci sequence in planning poker? [duplicate]

I've noted that fibonacci sequence is quite popular in planning poker, but is it a reason for that particular sequence? Wouldn't for example powers of 2 work equally well?

Both sequences are more or less exponential while fibonacci uses a factor of the golden ratio (approximately 1.6) so fibonacci has somewhat higher resolution and would allow to express more accurate(*) estimates.

Is there for example any evidence that people tend to be able to estimate accurate enough to motivate the higher resolution? And if there is wouldn't a even finer scale be motivated?

This question is not why one uses an exponential scale, but rather why choose the base of the golden ratio (which corresponds to the fibbonacci sequence). I think that the resolution of the scale should be in line with the estimation error you have. Therefore I don't think this is the same as What's the best explanation of what Story Points are?

(*) Here "accurate" means low level of estimation error. A quality that can be compared (an estimate is more or less accurate).

• @Neil, the "standard" set of numbers in planning poker are 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞. The Fibonacci sequence is 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55... That planning poker sequence is just a modified version of the Fibonacci sequence. Commented May 28, 2019 at 7:25
• "estimate accurate enough". This is an oxymoron. If you can be accurate, then you aren't estimating. You know how long it'll take, rather than estimating it. The purpose of schemes like planning poker is that it handles the uncertainty of estimation well: the bigger the estimate, the more uncertainty and thus the bigger gaps between numbers. Any exponential sequence will do for this. The commonly used sequence has just become the de facto "standard" due to popularity. Commented May 28, 2019 at 7:29
• @skyking in an agile setting you are not estimating the time a task will take, you are estimating how complex it is. Duration is of no relevance. And estimation-error rate increases with complexity. Also, agile suggests that you break a story down into smaller parts if you have a big uncertainty. Something with +100/-50% uncertainty should never make it into sprint commitment. Commented May 28, 2019 at 13:47
• Those of you who are saying that accuracy plays no part in the estimation process, or that time is not a factor, are simply wrong. Accuracy in estimation is expressed by your degree of certainty (or uncertainty) in your estimate; it can be improved by dividing up your work into smaller incremental steps and estimating those separately. It's entirely about time; otherwise, what is the point of an estimate? The time estimate is found by multiplying your story points by your team's velocity. Commented May 28, 2019 at 14:47
• @skyking If a team fails to deliver the Sprint goal there is no excuse. All you can do then is realize what went wrong and do that better next time. And yes, I've worked in a project where we had a good and constant velocity for almost the entire time and still failed to deliver all the requested features by the deadline set by the customer. And you know who's fault it was? That of management. They committed to a deadline not knowing whether the capacity in the team sufficed. Luckily, nobody blamed the team. Commented May 28, 2019 at 16:37

Production

What are you estimating? The time to manufacture something?

This has been solved for decades in Software Development.

Here is the process:

1. Copy the file/folder to the Clients Machine.

Done.

Estimated time 5 minutes (give or take 2 weeks depending on delivery mechanism and size).

Design

Given that manufacture is so simple, you are probably interested in estimating the time for designing.

Design can be split into two parts.

1. Research
2. Arrangement

Generally speaking Arrangement is the easier part, given a client that is willing to co-operate.

Research

Simply go out and find out that which is not known, then spend time to know it.

This is frankly impossible to estimate. As an observation take a look at predictions for: Fusion Power, Cancer Cures, Mars Colonisation, Self-programming Computers, etc...

When there exists something unknown, you simply cannot guess its size. The only proxy you have are any past experiences in the area.

Those past experiences are probably skewed representations themselves. If they shared a lot in common with your goal then you are not conducting Research but Arrangement.

Arrangement

Given a box full of previous designs re-arrange the ideas/components to produce what was asked for.

The benefit here is that the components/ideas have already been designed. If work has to occur to create/alter them, there already exists a well established methodology for their construction/alteration. (If not then this is Research.)

Given that there is a well known methodology, it is estimable based on the time taken by previous endeavours to produce/alter those components in the same way.

Estimating

What this means is that design is a balancing act of Researching the new knowledge, and Arranging that newly acquired knowledge with an older box of designs.

The problem is that most software projects are not in the later category very often. Which means a lack of standardised methods and estimations.

Those that are in this later category have generally speaking already been turned into commodity components. The estimated time to obtain these is approximately 5 minutes. (Obviously not for the first usage, but as the component is reused within the team).

Poker Face

What that leaves is the unknown.

The unknown, is by definition unknown.

So obtaining an accurate (or even proximally accurate) estimation is simply impossible.

However just because the unknown does not blink, does not mean that we cannot estimate our own lack of knowledge with regard to what is known.

Logarithmic Machines

Humans are logarithmic machines by nature, which means we are really sensitive to small differences at close to known, but crappy at handling similar discernment on larger scales.

What this means is that when the task, and the unknown element are small humans are great are judging it. These tasks are essentially arrangement.

Unfortunately a task which is Huge, or a task that is very uncertain, do not fit into comprehension (by definition). To make it fit humans abstract it down. This means that what appears to be a little increase in size/uncertainty translates into a huge difference in actual effort needed. In short Research.

This is why the series needs to be exponential. Its simply the most practical crutch to translate human logarithmic judgement to something vaguely linear.

As to which series to use. That is a mater of taste, and team preference. Which crutch best fits the teams own logarithmic distribution.

• I'm fascinated at the sheer amount of hand-waving here. As software developers, why can't we simply admit that we just suck at estimation? Commented May 28, 2019 at 14:57
• @RobertHarvey Where is the hand waving? I'm curious to see how bad the mud map I drew is. Commented May 29, 2019 at 0:09
• @RobertHarvey, as humans, we suck at estimation of new things. And in software, almost everything we do is a new thing. So why are developers so keen on self flagellation? And I see very little hand waving in this answer; I thought it a brilliant summary of the challenges for anyone attempting to estimate software. Commented May 29, 2019 at 8:13

Uncertainty will increase with the number of steps to take and with the length of the steps. So you will likely increasingly divert from your estimate as the task to take on gets bigger, your estimates should become more coarse. We all get that.

The trajectory of the coarseness is debatable. We at work recently suggested to drop the cards and switch to "quick", "medium" and "big" because it is really hardly ever more accurate than that anyway. It is just all to give people a sense of control which is hardly ever justified. Using a Fibonacci range adds to the feeling you are doing something that makes sense (science! math!). You can justify it with something like my first paragraph and everybody will be happy.

It is a continuous path of lulling each other into a sense of control. If you find any task takes (a lot) longer than anticipated, you just spin off a new issue and call the initial issue done. And your velocity adds up nicely. Call it a pacifier, call it scrum, call it something to keep you going when things look desperate. The math behind the card does not really mean that much, it is all just a way to keep in touch with each others state of mind about the work to be done.