估算並非易事。對軟體開發人員來說，估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此，從開發到高管都為它焦頭爛額也不足為奇，但這種做法是錯誤的。敏捷估算並不是什麼性命攸關的大事，就只是估算而已，事實就這麼簡單。
我們不用要求團隊週末加班加點來彌補一項被低估的工作。換句話說，與其事後補救，不如事前看一看有什麼方法可以讓敏捷估算盡可能變得更精準。
與產品負責人（po）合作
敏捷開發中，產品負責人 要負責確定backlog的優先順序次序——即乙個按優先順序排好序的工作列表，其中包含關於產品所有所需完成的功能和修復的缺陷的簡短描述。產品負責人能夠從業務中提取需求，但他們不一定了解具體如何實現。因此，精準的估算能讓產品負責人對每個工作專案的工作量有新的了解，這對他們評估每個專案的相對優先順序能起到一定作用。
開發團隊開始估算後，關於需求和使用者故事的問題會經常出現。這是一件好事：這些問題可以幫整個團隊更加充分的理解工作。對產品負責人來說尤為特別，將工作項拆解為粒度較小的任務，然後通過估算故事點幫助他們確定所有（和可能隱藏的）工作的優先順序。而一旦他們得到開發團隊的估算後，可能會再重新排列backlog中的工作項。
敏捷估算是一項團隊工作
敏捷估算的關鍵在於全員（包括開發人員、設計人員、測試人員、部署人員……等等）參與。團隊每個成員都能就產品和需要交付的工作貢獻乙個使用者故事。例如，如果產品管理者想要實現支援新瀏覽器這一看似簡單的功能，開發和qa就需要謹慎權衡，因為他們的經驗告訴他們這個看似簡單的需求背後可能隱藏巨大的困難。
同樣的，設計的變更不僅要設計團隊的投入，還需要開發和qa人員的參與。缺乏全員參與的估算會降低估算質量，也會導致團隊士氣低迷，因為關鍵的貢獻者會認為自己被排除在外。所有這些因素都會影響最終交付的軟體質量。
因此，不要讓你的團隊成為封閉估算的受害者。封閉狀態下的估算只會加速失敗。
故事點和小時數
傳統的軟體開發團隊以時間為單位來估算工作量，例如：天、周、月等等。而敏捷團隊大多採用故事點為計量單位。故事點的相對規模（工作量）用斐波那契數列如0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100表示。這聽起來似乎有點有違常理，但這種抽象的表述實際上能夠促使團隊針對工作的難點做出更果斷的決策。下面是使用故事點的幾點原因：
以日期為單位，無法計量那些無法避免的非專案相關的工作，如需要團隊成員參與的電子郵件、會議和訪談等。
日期可會存在一定的感情因素，而相對估算則可以剔除感情因素。
每個團隊估算工作的範圍略有不同，這意味著團隊的速度（以故事點為計量單位）自然也會有所不同。反過來，這樣就可以避免出現以速度為爭端的團隊間的勾心鬥角。
一旦團隊就每個故事點價值的相對工作量達成一致，團隊就可以在無爭議的情況下實現點數的快速分配。
故事點能夠激勵團隊成員以工作難度而非耗費的時間為基礎來解決問題。這確保團隊成員能專注於價值交付，而不是強調花費了多少時間。
故事點和計畫撲克
使用故事點進行估算的團隊會用計畫撲克的形式來統一團隊的估算值。團隊從backlog中抽取乙個工作項，簡單地討論之後，請每個成員在腦海裡構思乙個估算。然後每個人拿一張卡片，寫下自己的估算值，由scrum master收齊卡片後展示每位的估算值。如果估算一致，那麼討論結束，如果存在不同的估算值，就花點時間（無需太久——幾分鐘即可）了解為什麼成員給出了不同的估算。記住，估算討論應該抓大放小、提綱挈領，如果團隊過於糾纏細節，則暫停討論，提公升討論的水平和高度之後再繼續。
精準估算講究效率，無需浪費時間
任何單個任務都不應花費超過16小時。（如使用故事點，則可以設定20個故事點為上限）。如果單個工作項超過這一工作量，對其進行精準估算會更難。而精準估算對於位於backlog頂部的工作項來說尤為重要。如果單個工作項的估算超過了16小時（或20個故事點）的上限，意味著我們需要將其拆分為更小的工作項並重新進行估算。
對於那些位於backlog下方的工作項，可以只進行粗略估算。因為等到團隊真正開始要做該工作項時，需求可能已經發生了變化，相應的應用程式肯定會有所變化。因此，先前的估算可能就會不那麼準確。所以不要浪費太多時間去估算那些可能會發生變更的工作項。只需要提供粗略的估算，為產品負責人提供乙個可以用來確定產品路線圖優先順序次序的大概資料即可。
借鑑以往估算的經驗
回顧會議是團隊從已完成的迭代中總結經驗教訓的機會，當然也包括估算準確性總結。很多敏捷工具可以跟蹤故事點，這讓團隊可以更輕鬆地反思和調整估算。例如，我們可以嘗試提取過去故事點估算值為8 的5個使用者故事，討論每個工作項的工作量是否大致相同。如果存在差異，討論其背後的原因。然後將討論得到的經驗用於未來的估算。像敏捷的其他實踐那樣，估算也是一項熟能生巧的實踐。因此團隊肯定會越做越好。
敏捷開發（三） 估算故事
前兩篇文章介紹的是 蒐集故事和編寫估算，本篇文章接著前面的文章往下說，有了story 故事 之後如果對故事進行估算 下面主要是進行估算的大體checklists 對與乙個故事的估算方法應該具有如下特點 1 執行改變估算結果 2 適用於所有的故事 3 很容易很簡單的進行估算，不需要花費太多時間 4 提...
敏捷開發每日一貼 敏捷估算方法
敏捷估算方法 無論是團隊研發一款產品或者開發某乙個專案，我們都需要回答 我們大概什麼時間能夠完成？或者到某乙個時間點，我們能夠做到什麼程度，因此和傳統的開發模式一樣，我們在故事拆分之後需要對我們需要做的事情進行工作量的估算。相對於傳統的工作量估算方式，敏捷估算有如下幾個特點 1.團隊集體估算 在sc...
敏捷開發一千零一問系列之三十 敏捷怎樣估算（中）？
這是敏捷開發一千零一問系列的第三十篇。在這裡提問，之一 之二，之三 問題總目錄 續前文，預計未來還要有一篇，暫時做為中篇。這個在之前談到過很多次了，具體可以 參考敏捷開發績效管理系列 的之六 之七。另外在敏捷開發使用者故事分類與組織結構 一期 整個活動1期 中有詳細描述。這個是國際上迄今為止唯一被大...