在某開發團隊輔導的第二天，乙個團隊負責人諮詢道：「領導經常管我要開發計畫，我如何能快速的評估出預計開發完成時間呢，我們目前用工時估算，我聽說過故事點估算，不知道適合嗎？」
從這個團隊負責人那裡了解到，領導一般在接到專案大量新需求時會問這個問題。領導需要做到「心裡有數」，有乙個預計的專案新需求完成時間。加上領導一直做傳統的瀑布開發專案，他非常關心專案中遠期計畫，也就是我們通常講的里程碑或關鍵結點的問題。
團隊目前使用敏捷開發方式初期，團隊成員本身也對如何更快、更好地做好估算感到困惑，目前糾結是否應該採用故事點估算。
從以上問題分析中可以得出：第一，團隊對故事點不了解，需要學習什麼是故事點；第二，解決如何快速提供給領導開發計畫的問題。
解決問題我們來分兩步走。首先解決不熟悉故事點的問題，先給大家介紹一下故事點的定義及特性。然後大家了解一下兩層估算即產品待辦列表估算和sprint待辦列表估算的簡單區別，解決開發計畫的問題。
如果有時間，建議可以先看看上篇《如何估算第二篇：利用核心概念理解估算》了解估算的核心概念。然後再來看這篇文章效果更好。這篇文章主要講故事點。具體的估算方法有沒有比較好的實踐呢？在《如何估算第四篇：利用2種常見方法做估算》中會介紹幾種比較好的估算方法，包括：「計畫撲克估算」、「敏捷估算2.0（agile estimating 2.0）」等。本篇仍然在為估算做技能儲備（磨刀不誤砍柴功），即明確什麼是故事點。前面文章已經講過估算的乙個核心概念即估算相對大小，這個相對大小我們用故事點為單位。工時和理想人天相信大家都理解，不做過多解釋。在這裡著重從故事點的定義、故事點的特性兩個方面解釋下什麼是故事點，然後解決給領導提供計畫的問題。
故事點是表述乙個使用者故事，一項功能或一件工作的整體大小的一種度量單位。當採用故事點估算時，我們為每個待辦項分配乙個點數。待辦項估算結果的原生資料並不重要，我們只關注最後得到的相對估算結果。乙個估算值為2的使用者故事應該是估算值為1的使用者故事的2倍。而它也應該是另乙個估算值為3的使用者故事的三分之二。團隊不要採用100、200、300，而要使用1、2、3。估算結果是相對值，而不是絕對值。
「當使用故事點來估算使用者故事的大小時，並沒有固定的公式來規定如何計算故事點的數值。故事點估算用於評估為了交付乙個使用者故事所包含的工作量（team effort），使用者故事的複雜度(complexity)，風險，以及所有其他需要考慮的元素。——《agile estimating and planning》, mike cohn.
是相對單位
它是乙個相對單位。比如，不同的組織團隊，對於同樣的使用者故事的故事點大小一般是不同的；即使同一團隊，針對不同使用者故事的故事點大小，甚至是針對同一使用者故事的故事點大小，都允許是不同的。但同時提醒，不同團隊不同使用者故事的故事點的設定，有利於組織能力的積累和橫向參考。
不等同於工作量估算
故事點估算不是簡單等同於工作量估算。如mike cohn所描述，它包含工作量、技術含量、各方面制約等多方面價值因素。有時其他的這些因素，在故事點估算中占有比重會勝過工作量方面的考慮。
考慮「完成的定義」
故事點估算必須要覆蓋直到實現產品待辦項待真正完成的所有事項。如果團隊的「完成的定義」中包括了建立自動化測試來驗證這個故事（並且這是乙個好主意）這個事項，那麼建立這些測試的工作量也應該包含在故事點估算結果中。
如果一定要推薦工時（或理想人天）和故事點分別在什麼時候應用比較好，那麼我一般推薦在做產品待辦列表估算時用故事點，而sprint待辦列表估算時用工時（單位是小時）。
原因很簡單，結合最開始團隊負責人的問題，其實老闆大多對什麼時間點可以交付多少需求（使用者故事形式體現）感興趣。最常見的問題是：「這50個需求什麼時間可以做完？」很明顯，老闆並不是在問本sprint能做完多少需求，而是在問專案得有乙個預計的時間點或里程碑。換句話說就是，需要對某個時間點可以交付什麼樣價值做出乙個長期一點的**。如果每個故事平均15分鐘估算，那麼50個使用者故事估算需要50*15分鐘=750分鐘=12.5小時。顯然估算所需要花費的時間代價比較高，roi太低。如果採用準確度差不多的故事點估算，則效率會大大提公升。前面提到過為什麼故事點估算容易，這裡不再重複解釋。此時建議團隊平均3分鐘完成乙個使用者故事的估算，那麼估算需要50*3分鐘=150分鐘=2.5小時。這樣根據團隊正常速率，就可以預計完成時間，回答老闆的問題了。
對於sprint列表的估算，其目標更多的是要確定團隊本sprint要完成的工作量，故事點顯得有點抽象。團隊具體執行時，時間概念上有點困難，而小時數就容易得多。通常sprint列表項也會比產品待辦列表項少得多，所以時間上不會花費太多。另外，就sprint列表中的工作項而言，它會是更具體的需求，通常會進行任務細化和「完成定義」，進而很清楚如何去做，誰來做。這些因素綜合看，以工時（小時）來估算成為優勢。
參考附錄
1. mark c. layton. 敏捷專案管理[m].北京：人民郵電出版社。
點選關注，第一時間了解華為雲新鮮技術~
版本產品 產品經理如何利用敏捷思維進行版本迭代？
如果你遇到以上乙個或多個問題，那麼多半是開發模式存在問題。敏捷，字面意思是迅速 靈敏的意思，如 行動敏捷 思維敏捷 敏捷通常用於描述快速而靈活的完成某件事情。敏捷開發，就是快速而靈活的完成開發。在幾十年前，網際網路專案剛剛起步的時候，做乙個系統需要幾個月或者幾年 這類專案，與傳統的建築或工業專案類似...
如何利用資料庫建立Union 約束
為了少在client做db的邏輯判斷,可以盡量用db的union 約束來限制資料的重複輸入,那麼怎麼建立group users表中groupid,userid的union 約束呢?如下 drop table user group cascade constraints create table us...
如何利用診斷檔案監督資料庫例項
診斷檔案是一種獲得資料庫資訊的重要工具，對管理oracle資料庫例項是至關重要的，包含了資料庫執行過程中遇到的重大事件的相關資訊。幫助在日常工作中更好的管理資料庫。在oracle中有三類常見的診斷檔案 報警檔案altersid.log 後台程序追蹤檔案 使用者程序追蹤檔案。報警檔案包括了資料庫日常操...