小結：
1. 用故事點估算故事，故事點是故事複雜度、工作量、或工期的相對估算。
故事點有很好的特性是團隊可以定義自己認爲合適的故事點。一個團隊可能決定定義一個故事點爲一個理想日的工作。另一個團隊可能定義一個故事點爲一個理想周的工作。還有一個團隊可能把故事點作爲故事複雜度得測量。因爲故事點有很多的意義，所以Joshua Kerievsky認爲故事點代表事件的模糊單位，或叫NUT（Nebulous Units of Time）.
2.應由團隊估算故事，估算屬於團隊而不是個人 。
故事估算屬於團隊集體有兩個原因，第一，還不確定團隊中誰負責完成這個故事，所以應該把故事分配給整個團隊而不是個人。第二，團隊決定的估算可能比個人估算更有用。
估算步驟如下：
- 參與估算的客戶和開發人員 聚集在一起。客戶抽取故事，讀給開發人員聽。客戶儘可能給開發人員解釋疑點。
- 對故事沒有疑問後，每個開發人員 在卡片上寫下一個估算值。
- 大家都寫好值後，所有人展示自己的卡片，給別人看。這時，估算值可能差別很大，估算值高的和低的再解釋一下估算依據。
- 大家討論
- 重新估算
我們的目的是要爲故事得到一個統一的估算值。這個過程很少會超過三輪，但是只要是估算值不斷地接近一致，那我們就繼續這個過程。沒有必要讓所有人到在卡片上寫下完全一樣的估算值。點數要合理，而不是絕對精確。
3.通過和其他估算進行比較來進行三角測量
具體的做法就是在估算一個故事時，根據這個故事與其他一個活多個故事的關係來估算。假定一個故事的估算爲4個故事點，一個爲3個故事點，另外一個是2個故事點。把這三個故事放在一起考慮，程序員應該都同意4個點的故事大概是2個點故事的兩倍。3個點的故事大概比兩個點的故事大，比4個點的故事小。
使用故事點，在一輪迭代結束後，可以作爲下一個迭代認領故事點多少的依據。
4.團隊是否使用結對編程對故事點估算沒有影響。結對編程影響的是團隊的速率，不是他們的估算。
一些提醒：
要正確使用故事點，請記住下面幾點：
- 你的團隊的故事點和我的團隊的故事點是不一樣的。你的團隊估算的故事有3個故事點，可能我的團隊估算有5個故事點。
- 一個故事（可能是一個史詩故事）分解成一些小故事後，這些小故事的總和不需要與開始那個故事或史詩故事的估算相等。
- 類似地，一個故事分解成一些任務。這些任務估算的總和不需要與故事的估算相等。
開發人員職責：
- 負責用一個方式定義故事點，並且對團隊可用和相關的。努力保證這個定義的一致性。
- 負責給出誠實的估算。不屈服與誘惑或壓力而給出低的估算。
- 負責以團隊估算。
- 負責估算應與其他估算一致。即所有2點的故事都應差不多。
客戶職責：
- 負責參與估算會議，但是你的任務是回答問題並澄清故事細節。你不必參與故事估算。
