故事點是一個度量單位，用於表示完成一個產品待辦項或者其餘任何某項工做所需的全部工做量的估算結果。
當採用故事點估算時，咱們爲每一個待辦項分配一個點數。待辦項估算結果的原生數據並不重要，咱們只關注最後獲得的相對估算結果。一個估算值爲2的用戶故事應該是估算值爲1的用戶故事的2倍。而它也應該是另外一個估算值爲3的用戶故事的三分之二。
團隊不要採用100、200、300，或者1百萬、2百萬、3百萬，而要使用一、二、3。估算結果是比值，而不是絕對值。html
故事點包括什麼內容安全
因爲故事點數表明了開發用戶發故事所需的所有工做量，因此團隊的估算必須考慮到影響工做量的全部因素。這可能包括：微信
- 要開展的工做的數量
- 工做的複雜度
- 要開展的工做中存在的任何風險或不肯定性
在用故事點估算時，必需要考慮以上每個因素。讓咱們看看每一個因素是如何影響故事點的。app
要開展的工做數量（The Amount of Work）ide
若是要開展的工做越多，工做量的估算值固然就會越大。考慮兩個網頁開發的案例。第一個網頁只有一個字段和一個要求輸入姓名的標籤。第二個網頁有100個只須要輸入一小段文本的字段。工具
第二個網頁並不比第一個網友更復雜。字段之間是不存在交互的，每一個字段只不過是一點文本而已。所以第二個網頁並不存在額外的風險。這兩網頁之間的惟一區別就是第二頁有更多的事情要作。post
應該給予第二個網頁更多的故事點數。但它即便有多了100倍的字段數，可能仍然得不到多100倍的點數。畢竟，因爲規模經濟效應，第二個網頁的工做量可能只是第一個網頁的工做量的2或3或10倍。測試
風險和不肯定性（Risk and Uncertainty）spa
產品待辦項的風險和不肯定性會影響其故事點估算值。翻譯
若是產品待辦項的干係人在詢問需求事說得不清不楚，那麼團隊在估算時應當把不肯定性也反映在估算結果中。
若是要實現一項功能時須要改動一段缺少自動化測試的、結構脆弱的老代碼，那麼估算結果中也應該反映這個風險。
複雜度（Complexity）
在進行故事點估算時，還應該考慮複雜度。回顧一下以前那個有100個瑣碎文本字段且字段之間無交互的Web網頁開發的例子。
如今考慮另外一個也有100個字段的網頁。但這些字段中，有些是採用日曆控件彈出的日期字段；有些是格式化的文本字段，如電話號碼或社會安全號碼；另外一些字段則須要作信用卡號碼的校驗和驗證。
頁面上的字段之間還須要相互交互。若是用戶輸入一個VISA卡，會顯示三位CVV字段。可是若是用戶輸入美國運通卡，則須要顯示四位CVV字段。
儘管這個頁面上仍然只有100個字段，但這些字段更難實現。它們更復雜，須要花更多時間才能實現。開發人員出錯的可能性更大，所以不得不採起一些預防和糾正措施。
這種額外的複雜度都應該反映在所提供的估算結果中。
要考慮全部因素：工做數量、風險和不肯定性，和複雜度
把這三個因素合成一個數字並提供一個估算值，貌似是不可能的。然而實際上是可能的，由於能夠統一到工做量這個因素。
首先，估算人員要考慮的是：完成產品待辦項所描述的那些工做，到底須要多少工做量。
而後，估算人員要考慮的是：在處理產品待辦項的風險和不肯定性方面須要付出多少工做量。一般能夠經過考慮到問題發生的風險以及風險確實發生會形成的影響來作到。所以，例如，一個可能會發生並將消耗時間的風險將會增長估算值，而一個不太可能發生且可有可無的風險則不會增長估算值。
此外，估算人員還要考慮要開展的工做的複雜度。複雜的工做須要花費更多的心思，可能須要進行更多的試錯試驗，可能須要與客戶進行更多的反覆，還可能須要花費更長的時間來驗證和改正錯誤。
全部這三個因素必須都結合考慮。
要考慮「完成的定義」中的要求
故事點估算必需要覆蓋直到實現產品待辦項待真正完成的全部事項。若是團隊的「完成的定義」中包括了建立自動化測試來驗證這個故事（而且這是一個好主意）這個事項，那麼建立這些測試的工做量也應該包含在故事點估算結果中。
故事點多是個難以把握的概念。可是花時間去充分理解——故事點數表明着其工做的數量、複雜度及其風險和不肯定性——將會是值得的。
做者：Mike Cohn
翻譯：李潔（Jerry Li）
原文連接：https://www.mountaingoatsoftware.com/blog/what-are-story-points
關注Scrum中文網微信得到微信版估