前兩篇文章介紹的是 蒐集故事和編寫估算，本篇文章接著前面的文章往下說，有了story（故事）之後如果對故事進行估算
下面主要是進行估算的大體checklists
對與乙個故事的估算方法應該具有如下特點
1、執行改變估算結果
2、適用於所有的故事
3、很容易很簡單的進行估算，不需要花費太多時間
4、提供進度和剩餘工作的主要資訊
5、計算不準確也不會有大問題
6、估算的結果可以用來指定發布計畫
一、以故事點的形式進行估算
故事點估算可以很好的滿足上面的特點的估算方法。團隊可以自定義合適的故事點，我們組內偏好把乙個完美工作日作為乙個故事點進行故事估算。
完美工作日就是理想工作日，一天8個小時內一直在編碼沒有任何其他的情況。當然現實情況可能不太相同.所以乙個完美工作日！=一天
二、以團隊估算
故事點應該是由整個團隊進行估算，團隊中的大部分成員都要參與故事的故事點估算，每個人都把自己的估算結果說出來，最後大家再定乙個所有人都認可的故事點
三、如何進行估算
1、所有參與的客戶和開發人員聚在一起
2、從第乙個故事開始，詳細講解故事直到所有的人都清楚了解這個故事
3、每個開發人員都先寫下自己估算的值，一故事點為單位 ，例如 2完美工作日(2天)
4、大家都展現自己的估算，然後每個人都說一下為什麼估算出這個值
5、最後經過論證團隊估算出乙個所有人都認可的值
6、繼續下乙個故事的估算
有了解scrum的朋友應該可以感受到上面的流程基本上和scrum估算故事的流程是一樣的.
四、對評估的結果做三角測量
在做了幾個估算以後，對估算結果做三角測量，具體做法如下
在估算乙個故事時，根據這個故事與其他乙個或多個故事的關係來估算，假定乙個故事估算為4個故事點，第二個故事為2個故事點，把這2個故事放在一起考慮的時候，程式設計師都應該認可 4個故事點的故事是2個故事點的故事的2倍
其他3個故事點的故事的大小應該介於4個故事點的故事和2個故事點的故事之間。
如果上面的三角測量的結果不對，團隊就應該重新估算。
五、結對程式設計對故事點的影響
如果使用結對程式設計，故事點的估算應該是結對後進行的估算
小結
用故事點估算故事，故事點是故事複雜度，工作量或工期的相對估算
應由團隊進行估算故事，估算屬於團隊而不是個人
聽過其他估算進行比較做三角測量
團隊是否使用結對程式設計對故事點估算沒有影響，結對程式設計影響的是團隊的速率，不是他們的估算
開發人員的職責
負責用乙個方式定義故事點，並且對團隊可用和相關的，努力保證這個定義是一致性
負責給出誠實的估算，不屈服於**活壓力而給出低的估算
負責以團隊估算
負責估算應與其他估算一致，即所有相同故事點的故事的大小都是差不多的
客戶職責
參與估算會議，回答問題和澄清故事細節。
敏捷開發中故事點和估算的秘密
高質量的估算能夠幫產品負責人優化效率和衝突。因此，精準估算的重要性毋庸置疑。估算並非易事。對軟體開發人員來說，估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此，從開發到高管都為它焦頭爛額也不足為奇，但這種做法是錯誤的。敏捷估算並不是什麼性命攸關的大事，...
敏捷開發精準估算
估算並非易事。對軟體開發人員來說，估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此，從開發到高管都為它焦頭爛額也不足為奇，但這種做法是錯誤的。敏捷估算並不是什麼性命攸關的大事，就只是估算而已，事實就這麼簡單。我們不用要求團隊週末加班加點來彌補一項被低估...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...