故事點的主要好處

如果說故事點是對正在做的事情的時間（工作量）進行估計，那為什麼不直接估算出要多少個小時或多少天呢？為什麼要使用故事點呢？

亨利一世最終確定「一碼」就等於國王的鼻子到伸出的拇指之間的距離。這樣，就有了乙個標準的計量單位，即方便了國王自己，也方便了所有人。

你可能知道，一碼比自己自己的胳膊要長點或短點。我也是。但還好，我們有乙個共同的計量單位。

故事點數可以用這個故事進行模擬。就像英國的度量單位「碼」一樣，它允許不同技術水準的團隊成員能在溝通後得到乙個估算值。比如你和我決定出去跑步。我喜歡跑步，但是我跑得很慢。而你，相反跑得很快。你指著一條跑步路線說：我們跑這條路吧，這大概要花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點。

綜上，就像定義了國王亨利的鼻子到他的拇指的距離，故事點的定義就能使不同速度的程式設計師在估算時能達成一致。