估算介紹
在以前開發 IT 軟體時，使用較多的衡量軟體開發工作量的單位是：小時、人天 或 人月。它是預估開發時間。比如：這個功能張三一個人開發需要 3 天時間完成。
這種 “人天” 估算只是 “理想人天” 的估算，有時與實際開發完成所需天數有很大差別。因為每個人完成同樣複雜度工作所需的時間是不同的。
那在敏捷 Scrum 框架中，使用者故事的開發工作量，如何估算一個使用者故事開發工作量？估算開發任務工作量是一件很困難的事情，它需要考慮的因素有很多，包括：
- 使用者故事的規模大小
- 業務複雜度、難度
- 業務規則複雜度
- 開發人員能力大小、個體差異
- 團隊成員休假、有事請假等突發因素
等等各種因素。
雖然很困難，但是智慧的人們還是給出了一些估算的方法，幫助 Scrum 團隊對開發任務進行估算。下面介紹幾種估算的方法。
估算在 Scrum 的哪個環節呢？
一般在 Sprint 計劃會議上。
當產品負責人和 Scrum 團隊人員選擇好了 Sprint backlog 裡的待開項，也對大的開發項進行了拆分。對不理解的一些開發項，相關負責人也進行了解釋，團隊成員理解也達成了一致。這時就可以進行開發任務工作量的估算了。
故事點Story Point
故事點介紹
什麼是故事點 Story Point？
故事點是一個度量單位，完成某項開發任務所有工作量的估算結果。被估算的不是花費的時間長短，而是工作量多少。
故事點一般用來衡量使用者故事或任務的工作量、複雜度和不確定性，它不是傳統的估算方法：小時 或 人天。它不依賴具體的開發人員或開發速度，更多強調團隊內部討論，協商一致性和相對估算。
不同於預估完成任務所需時間長短，故事點關注的重點是複雜度和不確定性。
它是一個相對度量單位，一般是相對於基準故事。
在做故事點度量估算時，會選擇一個基準故事（一個已知大小和複雜度的故事）作為基準點來參考，其它故事相對這個基準故事來做度量，對故事工作量進行估算。
然後額外考慮故事的複雜度因素、風險因素、不確定性因素，並且為這些額外的因素加上點數，這樣估算出來的故事點數相對來說正確性就提高了許多。
故事點數 = 完成故事所需工作量 + 複雜度因素點數 + 風險因素點數 + 不確定性因素點數
注意：
- 1、 這裡的點不代表任何時間長度。它只是一個工作量多少的度量單位。
估算數值選取
通常採用斐波那契數列，如 0、1/2、1、2、3、5、8、13，20，40，100；有時也採用自然數來替代，如 1，2，3，4，5，6。
具體情況要看故事之間的大小差別，怎樣的數字間隔更加適合團隊估算的情況。
斐波那契數列稱為黃金分割數列，隨著數字間距的擴大，對於顆粒度較大的需求更加便於我們判斷選擇哪個數字。
估算故事點簡單流程
1、選擇基準故事
團隊先選擇一個已知的使用者故事作為“基準故事”，這個基準故事的任務複雜度和工作量是團隊成員已知且易於理解的任務，然後給這個基準故事打一個故事點值（比如 3）。其它故事就和這個基準故事進行比較。
2、討論和理解故事
在估算其它使用者故事或開發任務時，要確保團隊成員對任務的需求、複雜度、潛在風險的理解相一致。大家一起提問、討論問題，產品負責人進行解釋回答。
3、選擇估算值
討論完成後，團隊成員各自獨立選擇，選擇認為合適的故事點數值（如 3，5，8）。每個人的估算都應該是基於對任務相對複雜度、風險因素的理解上，而非實際工作時長。
4、展示估算結果
團隊每個成員獨自選擇估算值完成後，所有人同步一起展示選擇的數值。如果估算結果一致，則記錄下該數值；如果估算結果值差異較大（比如一個是 3 ，一個是 13 ），則需進一步討論。
5、 討論估值差異後達成共識
當出現較大估值差異時，團隊成員需要解釋為什麼選擇該值。在討論中，透過進一步澄清需求細節、拆解任務等方式，幫助團隊成員更好地理解任務的複雜度，從而達成共識。
達成共識後，記錄下最終討論的估值數。然後進行下一個故事估算的討論。
計劃撲克估算
計劃撲克估算，和上面的故事點估算，做法大同小異，它把故事點估算透過遊戲化的方式來進行，改進了估算方式體驗。
計劃撲克是透過遊戲化方式來進行估算，帶有一點娛樂性質，體驗效果可能會更好。
計劃撲克介紹
在敏捷框架下，Scrum 團隊是一個自組織團隊，團隊決策多數是集體協商，共同承諾。計劃撲克就是一種集體估算的工具，透過遊戲化的方式來進行估算，鼓勵團隊成員充分表達意見。
計劃撲克是一種基於團隊共識的估算方法。團隊成員每人會拿到一套特製的卡片（撲克牌），卡片上標有數字，這些數字通常是斐波那契數列（如 0、1/2、1、2、3、5、8、13，20，40，？，∞ 等），卡片上數字大小表示對任務估算的估值數。
- “∞” 卡用來表示估算者不認為這項任務能夠完成
- “？” 卡用來表示估算者無法進行估算
有的還有一張 咖啡 卡牌 ，表示估算久了，需要休息片刻。
有的團隊也用自然數排列的牌，也可以，根據被估算的故事差異大小而定。
參與人數
一般是 4 - 8 人，參與人數太多，會拉長估算的時間，降低估算效率；人數太少，會導致估算結果偏差大。
計劃撲克遊戲過程
1、講解使用者故事
產品負責人從 Backlog 中選擇一個待開發項（使用者故事或任務），然後為大家進行簡要的介紹。
2、討論故事需求
團隊成員針對該開發故事進行討論，提出問題，產品負責人負責解答所有問題。
這一步是團隊成員和產品負責人進行互動討論：理解需求、實現細節、潛在風險等等，幫助團隊成員和產品負責人對開發的需求理解是一致性。
這時，產品負責人可以根據大家的反饋，及時修改並完善開發項（需求）。
3、選擇估算值
3.1、選擇基準故事
估算時，常用的是相對估算值，不是絕對估算值。跟上面的故事點估算一樣，會選擇一個大家易於理解的故事作為一個基準故事，比如這個基準故事故事點值為 3，然後其它故事和這個基準故事比較，得出估算的相對點數值。
3.2、進行估算
團隊成員已經對該開發故事有充分了解，沒有問題後，大家就根據自己的理解和經驗，各自獨立選出一張代表自己估算值的卡牌，卡牌面朝下放置，不明牌。
這一步團隊成員之間不可相互討論估算值。
團隊成員估值都完成後，大家同時亮牌，展示各自估算結果。
4、討論估值差異
若每個成員對使用者故事的估值差距不大，則記錄下估值；
若每個成員對使用者故事的估值差距較大，說明大家對該使用者故事的理解、價值沒有達成共識，大家需要解釋為什麼這樣估值？然後對估值結果進行討論。
例如第一輪估值亮牌結果為：3，3，8，13。這 4 個估值數明顯 1 個偏大（與平均值對比），2 個偏小，大和小差距過大。平均值為 6.75，四捨五入為 7。
兩個估值數 3 過小（偏離平均值）的成員需要解釋為什麼這樣估值？估值數 13 過大的成員也需要解釋為什麼？然後大家對給出的解釋一起討論，對需求開發不同認知點、懷疑的點進行討論。
討論注意點：
- a、敏捷教練要維護活動秩序，避免不必要的爭吵和跑題。
- b、無需深入程式碼細節，這是開發人員最愛跑題項之一。
- c、鼓勵大家都發言，不能總是某幾個人發言討論。
大家討論完成後，再進行估值。重複上面的第 3 、4 步驟。一般經過 2 到 3 輪就可以得到一個相差比較近的估值。
如果第 3 輪估算結束後，大家還沒有得到一個相近的估值，那就取一個大家認可的平均值作為估算結果。
差距大時，估值討論不能無盡迴圈下去，這樣會浪費大家本可以做其它工作的時間。這也是撲克估算的缺點，有時會耗時。
估值的目的，第一，大家都瞭解故事開發的複雜度和工作量；第二，大家瞭解所做的詳細工作有哪些；第三，大家對做的工作能有一個共識。
團隊成員需要在儘可能短時間內，達成一個一致的估值結果。
其它估算方法介紹
親和估算（Affinity Estimating）
親和估算首先需要在一個白板或者牆上劃分出不同的區域，每個區域代表一個工作量範圍（同樣可以用故事點來衡量），例如分為 “小（1 - 3 個故事點）”、“中（4 - 8 個故事點）”、“大（9 - 13 個故事點）” 等區域。
然後將所有的使用者故事寫在卡片上，團隊成員一起把這些卡片按照自己對使用者故事工作量的判斷，放置到相應的區域中。在放置過程中，團隊成員可以對每個使用者故事進行簡單討論，確定其所屬的工作量範圍。
優點： 相對來說估算比較快速，能夠在短時間內對大量使用者故事進行初步估算。幫團隊成員整體上把握使用者故事的規模。
缺點： 它的估算精度相對較低，因為只是將使用者故事劃分到大概的工作量範圍，沒有像計劃撲克那樣精確到具體的數字。還有團隊成員對工作量理解不一致，導致使用者故事放置混亂，需要花時間重新討論和調整。
功能點數估算
功能點估算方法是從使用者的功能需求角度出發，透過計算使用者故事中的功能點數來估算工作量。
比如後臺使用者管理功能，可能有增加、刪除、修改、搜尋、檢視使用者詳情等功能。
優點： 以功能需求點為基礎，比較客觀，能一定程度上避免團隊成員主觀因素導致的估算偏差。它適用有詳細需求文件的情況下，可以較準確估算工作量。
缺點： 功能點估算方法需要對系統的功能有詳細的分析和定義。計算功能點數需要一定的專業知識和經驗，而且不同的人對功能點的計算標準可能會有差異。此外，它沒有考慮到非功能因素（如效能要求、安全要求等）對工作量的影響，可能會導致估算結果不夠全面