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.
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.
"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...
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".
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.
发布评论
评论（6）
斐波那契数列只是指数估计尺度的一个示例。使用指数标度的原因来自信息论。
我们从估计中获得的信息的增长速度远远慢于估计的精度。事实上，它以对数函数的形式增长。这就是较大项目的不确定性较高的原因。
确定指数尺度的最佳基数（归一化）在实践中很困难。与斐波那契数列相对应的基数可能是最优的，也可能不是最优的。
以下是数学论证的更详细解释：http://www .yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
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
在斐波那契数列的前六个数字中，有四个是质数。这限制了将任务平均分解为更小的任务以让多人并行处理的可能性。这样做可能会导致误解，认为任务的速度可以与处理该任务的人数成正比。 2^n 系列最容易出现这样的问题。事实上，斐波那契数列迫使人们一项一项地重新评估较小的任务。
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.
根据这个敏捷博客
是的，对。我认为这是因为它们为本质上非常高水平的早期规模调整（而不是范围界定）练习（确实有价值）添加了合法性（斐波那契！数学！）。
但您可以使用 T 恤尺码获得相同的结果......
According to this agile blog
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...
你肯定想要指数级的东西，这样你就可以用恒定的相对误差来表达任何时间量。您估计的精度也很可能与您的估计成正比。
所以你想要一些东西：
a) 带有整数
b) 指数
c) 简单
现在为什么用斐波那契数而不是 1 2 4 8 呢？
我的猜测是，这是因为斐波那契增长速度较慢。它的单位是 goldratio^n，并且 goldratio=1.61...
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...
斐波那契数列只是项目规划扑克中使用的数列之一。
准确估计大型工作单元是很困难的，如果你的数字太“现实”，很容易陷入数小时与数天的讨论中。
我喜欢 http:// /www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/，即斐波那契数列代表了一组我们可以直观地将它们区分为不同的大小。
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.
我使用斐波那契有几个原因：
一项特定的任务，这也增加了不确定性
对于计算机来说，复杂两倍的任务可以用双倍的时间解决
对于开发人员来说可能需要更多的时间。
当我们把所有的不确定性加起来时，我们不太确定实际的工作时间应该是多少。如果我们能够衡量这项任务是否比我们已经给出估计的另一项任务更大/更小，那么结果会更容易。随着任务规模/复杂性的增加，不确定性的影响也会放大。我很乐意将一项任务估计为 13 小时，而该任务似乎是我之前估计的 5 小时任务的两倍。
I use Fibonacci for a couple of reasons:
a particular task so that adds to the uncertainty too
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.