为什么在敏捷规划扑克中使用斐波那契数列?

在估算敏捷软件开发中用户描述的相对大小时,团队成员应该估算出用户描述的大小为1,2,3,5,8,13,... ..。所以估计值应该类似于斐波那契数列。但我想知道,为什么?

维基百科上对 http://en.wikipedia.org/wiki/Planning_poker的描述中有一句神秘的话:

使用斐波那契数列的原因是为了反映固有的 估计较大项目的不确定性。

但是,为什么在较大的项目中会存在固有的不确定性呢?如果我们减少测量,不确定性不是更高吗? 这意味着如果更少的人估计同一个故事? 即使不确定性在更大的故事中更高,为什么这意味着使用斐波那契数列?是否有数学或统计学上的原因? 否则,使用 Fibonacci 系列进行评估对我来说就像是 CargoCult 的科学。

132180 次浏览

You definitely want something exponential, so that you can express any quantity of time with a constant relative error. The precision of your estimation as well is very likely to be proportional to your estimation.

So you want something : a) with integers b) exponential c) easy

Now why Fibonacci instead of, 1 2 4 8? My guess is that it's because fibonacci grows slower. It's in goldratio^n, and goldratio=1.61...

The Fibonacci sequence is just one of several that are used in project planning poker.

It is difficult to accurately estimate large units of work and it is easy to get bogged down in hours vs days discussions if your numbers are too "realistic".

I like the explanation at http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/, namely the Fibonacci series represents a set of numbers that we can intuitively distinguish between them as different magnitudes.

Out of the first six numbers of the Fibonacci sequence, four are prime. This limits the possibilities to break down a task equally into smaller tasks to have multiple people work on it in parallel. Doing so could lead to the misconception that the speed of a task could scale proportionally with the number of people working on it. The 2^n series is most vulnerable to such a problem. The Fibonacci sequence in fact forces one to re-estimate the smaller tasks one by one.

I use Fibonacci for a couple of reasons:

  • As task gets larger the details become more difficult to grasp
  • Task estimate is the number of hours for anyone in the team to complete the task
  • Not everyone in the team will have the same amount of experience for a particular task so that adds to the uncertainty too
  • Human gets fatigue over larger and potentially more complex task. While a task twice as complex is solved in double time for a computer it may take quite a bit more for a developer.

As we adds up all the uncertainties we are less sure of what the hours actually should be. It ends up easier if we can just gauge if this task is larger/smaller than another one where we gave a estimate of already. As we up the size/complexity of the task the effect of uncertainty is also amplified. I would be happily taking an estimate of 13 hours for a task that seems twice as large as one I've previously estimated at 5 hours.

According to this agile blog

"because they grow at about the same rate at which we humans can perceive meaningful changes in magnitude."

Yeah right. I think it's because they add an air of legitimacy (Fibonacci! math!) to what is in essence a very high-level, early-stage sizing (not scoping) exercise (which does have value).

But you can get the same results using t-shirt sizing...

The Fibonacci series is just one example of an exponential estimation scale. The reason an exponential scale is used comes from Information Theory.

The information that we obtain out of estimation grows much slower than the precision of estimation. In fact it grows as a logarithmic function. This is the reason for the higher uncertainty for larger items.

Determining the most optimal base of the exponential scale (normalization) is difficult in practise. The base corresponding to the Fibonacci scale may or may not be optimal.

Here is a more detailed explanation of the mathematical justification: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html