到底什麼是故事點（Story Point）？

故事點是乙個度量單位，用於表示完成乙個產品待辦項或者其他任何某項工作所需的所有工作量的估算結果。

當採用故事點估算時，我們為每個待辦項分配乙個點數。待辦項估算結果的原生資料並不重要，我們只關注最後得到的相對估算結果。乙個估算值為2

的使用者故事應該是估算值為

1的使用者故事的

2倍。而它也應該是另乙個估算值為

3的使用者故事的三分之二。

團隊不要採用100、200、300，或者1百萬、2百萬、3百萬，而要使用1、2、3。估算結果是比值，而不是絕對值。

故事點包括什麼內容

由於故事點數代表了開發使用者發故事所需的全部工作量，所以團隊的估算必須考慮到影響工作量的所有因素。這可能包括：

在用故事點估算時，必須要考慮以上每乙個因素。讓我們看看每個因素是如何影響故事點的。

要開展的工作數量（the amount of work）

如果要開展的工作越多，工作量的估算值當然就會越大。考慮兩個網頁開發的案例。第乙個網頁只有乙個欄位和乙個要求輸入姓名的標籤。第二個網頁有100個只需要輸入一小段文字的字段。

第二個網頁並不比第乙個網友更複雜。字段之間是不存在互動的，每個字段只不過是一點文字而已。因此第二個網頁並不存在額外的風險。這兩網頁之間的唯一區別就是第二頁有更多的事情要做。

應該給予第二個網頁更多的故事點數。但它即使有多了100倍的字段數，可能仍然得不到多100倍的點數。畢竟，由於規模經濟效應，第二個網頁的工作量可能只是第乙個網頁的工作量的2或3或10倍。

風險和不確定性（risk and uncertainty）

產品待辦項的風險和不確定性會影響其故事點估算值。

如果產品待辦項的干係人在詢問需求事說得不清不楚，那麼團隊在估算時應當把不確定性也反映在估算結果中。

如果要實現一項功能時需要改動一段缺乏自動化測試的、結構脆弱的老**，那麼估算結果中也應該反映這個風險。

複雜度（complexity）

在進行故事點估算時，還應該考慮複雜度。回顧一下之前那個有100個瑣碎文字欄位且字段之間無互動的web網頁開發的例子。

現在考慮另乙個也有100個字段的網頁。但這些欄位中，有些是採用日曆控制項彈出的日期字段；有些是格式化的文字字段，如**號碼或社會安全號碼；另一些欄位則需要做信用卡號碼的校驗和驗證。

頁面上的字段之間還需要相互互動。如果使用者輸入乙個visa卡，會顯示三位cvv欄位。但是如果使用者輸入美國運通卡，則需要顯示四位cvv欄位。

儘管這個頁面上仍然只有100個字段，但這些欄位更難實現。它們更複雜，需要花更多時間才能實現。開發人員出錯的可能性更大，因此不得不採取一些預防和糾正措施。

這種額外的複雜度都應該反映在所提供的估算結果中。

要考慮所有因素：工作數量、風險和不確定性，和複雜度

把這三個因素合成乙個數字並提供乙個估算值，貌似是不可能的。然而其實是可能的，因為可以統一到工作量這個因素。

首先，估算人員要考慮的是：完成產品待辦項所描述的那些工作，到底需要多少工作量。

然後，估算人員要考慮的是：在處理產品待辦項的風險和不確定性方面需要付出多少工作量。通常可以通過考慮到問題發生的風險以及風險確實發生會造成的影響來做到。因此，例如，乙個可能會發生並將消耗時間的風險將會增加估算值，而乙個不太可能發生且無關緊要的風險則不會增加估算值。

此外，估算人員還要考慮要開展的工作的複雜度。複雜的工作需要花費更多的心思，可能需要進行更多的試錯試驗，可能需要與客戶進行更多的反覆，還可能需要花費更長的時間來驗證和改正錯誤。

所有這三個因素必須都結合考慮。

要考慮「完成的定義」中的要求

故事點估算必須要覆蓋直到實現產品待辦項待真正完成的所有事項。如果團隊的「完成的定義」中包括了建立自動化測試來驗證這個故事（並且這是乙個好主意）這個事項，那麼建立這些測試的工作量也應該包含在故事點估算結果中。

故事點可能是個難以把握的概念。但是花時間去充分理解——故事點數代表著其工作的數量、複雜度及其風險和不確定性——將會是值得的。

文章**：scrum 中文網