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

阿新 • • 發佈：2017-10-10

包括團隊 isa 通過定性及其只需要需要數量

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

當采用故事點估算時，我們為每個待辦項分配一個點數。待辦項估算結果的原生數據並不重要，我們只關註最後得到的相對估算結果。一個估算值為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個字段，但這些字段更難實現。它們更復雜，需要花更多時間才能實現。開發人員出錯的可能性更大，因此不得不采取一些預防和糾正措施。

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

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

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

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

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

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

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

要考慮“完成的定義”中的要求

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