story points應該怎麼使用

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

當採用故事點估算時，咱們爲每一個待辦項分配一個點數。待辦項估算結果的原生數據並不重要，咱們只關注最後獲得的相對估算結果。一個估算值爲2的用戶故事應該是估算值爲1的用戶故事的2倍。而它也應該是另外一個估算值爲3的用戶故事的三分之二。

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

故事點包括什麼內容

因爲故事點數表明了開發用戶發故事所需的所有工做量，因此團隊的估算必須考慮到影響工做量的全部因素。這可能包括：

要開展的工做的數量
工做的複雜度
要開展的工做中存在的任何風險或不肯定性
在用故事點估算時，必需要考慮以上每個因素。讓咱們看看每一個因素是如何影響故事點的。

要開展的工做數量（The Amount of Work）

若是要開展的工做越多，工做量的估算值固然就會越大。考慮兩個網頁開發的案例。第一個網頁只有一個字段和一個要求輸入姓名的標籤。第二個網頁有100個只須要輸入一小段文本的字段。

第二個網頁並不比第一個網友更復雜。字段之間是不存在交互的，每一個字段只不過是一點文本而已。所以第二個網頁並不存在額外的風險。這兩網頁之間的惟一區別就是第二頁有更多的事情要作。

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

1 story point是用來評估一個任務（Product Backlog）的難度，跟小時數沒有必然的關係。Story point須要使用斐波那契數列來表示（1,2,3,5,8...）。只因此用這個序列是要更好的顯示差別。

2 對管理層和team的做用是，你一個sprint完成了多少個point能進行顯示，那麼通過多個sprint以後你就能看到這個team的velocity了！3 Scrum是頭對頭，所以是全部的team成員進行投票。每人一副12358的撲克牌，進行投票並對決討論爲何這個story point是這個數字。此時不知道誰是執行人，減小認知誤差。4 不蛋疼。a.若是是一個難度是3的PBI，甲程序員完成可能10h，乙程序員可能須要8h，這個是一個方面。b.Sprint planning的時候你須要輸入每一個人的capacity吧，輸入這個小時數就能看見一個程序員是否是超工做量了。c.輸入完orginal time和remaining time就能產生burning down chart。這個chart對開發過程的重要性不用多解釋了吧。