如果说故事点是对正在做的事情的时间（工作量）进行估计，那为什么不直接估算出要多少个小时或多少天呢？为什么要使用故事点呢？
使用故事点来估算产品backlog条目的原因有很多，我在敏捷估算和计划课程的视频中已经很充分地探讨过，但是，我今天想说的是，故事点本身就自带一个令人信服的理由。
这里得先说说国王亨利一世（公元1100年到1135年在位）。在他继位之前，“一码”这个计量单位是从一个人的鼻子到他伸出的大拇指间的距离。想象一下，每个人的这个距离都是不同的，这该有多混乱啊？
亨利一世最终确定“一码”就等于国王的鼻子到伸出的拇指之间的距离。这样，就有了一个标准的计量单位，即方便了国王自己，也方便了所有人。
你可能知道，一码比自己自己的胳膊要长点或短点。我也是。但还好，我们有一个共同的计量单位。
故事点数可以用这个故事进行类比。就像英国的度量单位“码”一样，它允许不同技术水准的团队成员能在沟通后得到一个估算值。比如你和我决定出去跑步。我喜欢跑步，但是我跑得很慢。而你，相反跑得很快。你指着一条跑步路线说：我们跑这条路吧，这大概要花30分钟。
这条路我很熟，但是作为一个比你跑的慢的人，我心里清楚这要花我60分钟。所以，我告诉你，我和你一起跑这条路，但是需要60分钟。
所以我们争执起来30,60,30,60.
我们争执半天没有结果。也许我们可以妥协一下，需要45分钟?但是这也许是最坏的结果。因为我们虽然有了一个估算结果，但是，这个结果对大家都没什么好处。
所以，我们继续争论。30,60,30,60.
最终，你跟我说：Mike，这段路大概5英里，我能在30分钟内跑完它。
我说：我同意这段路程是5英里。但它要花我60分钟。
问题是我们两个都是对的。你真的能在30分钟内跑完，我也真的需要60分钟。当我们为这段路程加上时间估算，我们发现不能这样做，因为大家工作（跑步）的速率不同。
但是，当我们使用了一个抽象的度量衡–这个例子里是英里–我们就能达成一致。你和我都同意这段路程是5英里。我们仅仅在它要花费我们多长时间上意见不同。
故事点跟这差不多。它能使不同技术水平和工作速度的人在估算结果上保持一致。当然，这里的主角是具有不同产出率的程序员，而不是本例中跑得快的人和跑得慢的人。
就像这两个跑步的人，两个程序员也许同意一个用户故事是5个点（而不是5英里）。快一点的程序员可能觉得这很容易，1天就能完成。那个慢点的程序员可能觉得需要2天才能搞定。但是他们能在5个故事点这一点上达成一致。因为把第一个用户故事定成5个故事点是不需要什么依据的。
不过，最重要的是，一旦他们同意第一个故事是5点，这两个程序员就可以达成后续的估计。如果快速程序员认为一个新的用户故事将需要两天（两倍于他估计为5点的故事），他将评估新的故事为10点。而另一个程序员也会这样做，当她需要四个工作日（两倍于她估计为5点的故事），她将评估新的故事为10点。
综上，就像定义了国王亨利的鼻子到他的拇指的距离，故事点的定义就能使不同速度的程序员在估算时能达成一致。
作者：Mike Cohn
原文地址：http://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points
