一文說通用戶故事點數是什么？
?

?第26期：一文說通用戶故事點數是什么？

用戶故事點數是一種采用相對估算法進行估算的一種工具，一般采用斐波那契數列表征用戶故事里說的大小，采用0 1 2 3 5 8 13這樣的一些數字來表征用戶故事的大小，那么用戶故事點說到底是什么？

?我們在實現過程當中看到很多人理解的都是錯的。為了能夠澄清什么是用戶故事點數特編寫本文，以澄清視聽。

01

用戶故事點數和絕對工時沒有關系

用戶故事點數是一種相對估算的單位，它表征了一個用戶故事和另一個用戶故事之間的開發規模的相對關系，而并不表示它的絕對規模。

用戶故事點數和實際的工時沒有任何的比例關系。

以鑲地磚為例，鑲兩塊地磚的工作量是鑲一塊地磚的工作量的兩倍，這個和是張師傅來鑲還是李師傅來鑲是沒有任何關系的。

在一些開發團隊當中，會把用戶故事點數和工時進行一個比例設定，這個設定是錯的。

這個設定會導致了工作量失去了比例關系，而依賴于個人的生產能力。

同一個功能，不同水平的師傅來干，工時需要的不同，如果綁定這個關系則失去了相對估算的意義。

02

用戶故事點數表示了團隊的效率提升

每個迭代可以交付的用戶故事點數合計表示了團隊的速率。?

? ?

如果按照絕對工時作為度量單位，那么一個人一周只有40小時的工作時間，這是一個無法通過個人努力或者團隊努力而改變的客觀約束。

那么，在綁定故事點數和絕對工時的前提條件下，就無法表征出團隊的持續改進情況。

而采用和絕對工時無關的故事點數是可以表征出來團隊的改進情況的。

比如說，一個團隊，每周原來可以生產100個故事點數，而經過改進之后，在原來的同樣的估算體系下，已經可以每周交付120個故事點數的任務。那么這表示，團隊提升了20%。

但是如果采用了故事點數和絕對工時綁定的情況下。

原來一個團隊，一周可以交付200個工時（5人x40小時）的任務，現在一周可以交付240個小時的任務，那么反而表明這個團隊通過加班來完成任務，實際效率下降。

這是一種錯誤的估算方式。

所以，采用這種把用戶故事點數和絕對工時綁定比例關系的團隊，有這么幾種原因:

1. 不懂什么是用戶故事點數

2. 對持續改進沒有追求

這樣的團隊，趁早放棄敏捷比較好。

【特殊情況】

如果遇到特殊情況，上述速率公式仍然可以表征團隊的實際效率。比如，工程師小張這個迭代休假了，團隊從5個人變成4個人，交付的總故事點數從100變成了80。

但是速率沒有變化，以兩周迭代，每人80小時為例。

速率沒有變化

【不同的工程師速率就是不同的】

的確，不同的工程師開發速率是不同的，很多人對此有疑惑。

不同的工程師開發同一個功能效率可能差上幾倍乃至幾十倍。相對估算是不是表征不了這個特點。

不是的。

假設小張的速率是，每天可以交付8個故事點數，而小李可以交付12個。

那么

??

可以很客觀的反應二者的效率差，也能夠表明改進的著力點。

之后小張的速率提升了，那么整個團隊就提升了。

03

雜項要不要納入工時統計

團隊除了開發，還有很多雜項，那么統計工時作為分母的時候，要不要把這些雜項納入工時統計。

和加班一樣，所有團隊花費的工時都要納入統計。

同樣的，如果遇到節假日，工時縮短也一樣處理，這樣才知道應該怎么進行改進，比如雜項占用時間太多，那就應該想辦法減少雜項所耗費的時間。