敏捷實踐中使用故事點常犯的12個錯誤

原文做者：Maarten Dalmijn

原文地址：https://medium.com/serious-scrum/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7

譯者：付新圓&柴曉燕

幾乎每一個Scrum團隊都在使用故事點，但故事點不是官方Scrum指南的一部分，就存在不少不一樣的解釋和使用方法。本文旨在消除圍繞故事點的神祕感，也將分享我在敏捷實踐中遇到的對故事點的誤解。

故事點表明什麼？

故事點是用於估計敏捷開發中用戶故事的相對大小和複雜性的度量單位，表示投入PBI (Product Backlog Item產品待辦事項) 所需的工做。每一個故事點表明一個時間的正態分佈。例如：1個故事點能夠表示4-12小時的範圍，2個故事點能夠表示10-20小時的範圍，依此類推。這個時間分佈在預估過程當中是未知的。經過參考PBI (Product Backlog Item產品待辦事項) 獲得相對估計值，雖然不知道完成任務的具體時間，但能夠粗略地知道須要多長時間完成任務。

使用故事點有什麼好處？

故事點使團隊可以：

• 快速預估問題。預估能夠參考已經完成的產品待辦事項。這比沒有任何參考的預估要快。
• 估算時無需給出具體的時間承諾。以小時爲單位進行估算時，您須要作出精確的時間承諾。但估算故事點時，不須要作出確切的承諾，不須要對特定問題指定多少小時完成。
• 擁抱預估帶來的不肯定性。故事點指定了未知的時間範圍，從故事點的特定Fibonacci-like序列中進行選擇能夠捕獲不肯定性。
• 足夠準確，能夠提早計劃衝刺。能夠更好地管理利益相關者對將來工做的時間指望。

使用故事點時常見的12個誤區

1.講故事只是指複雜性，不肯定性或價值。

PBI (Product Backlog Item產品待辦事項)的實現須要複雜的算法。有些PBI (Product Backlog Item產品待辦事項)很複雜，但並不須要不少時間，團隊以前已經作過了此類的操做，因此他們能快速完成。相反的狀況也會存在，好比一個簡單的PBI須要不少時間，團隊須要重構一小段代碼，但影響了不少功能，結果許多功能須要進行迴歸測試，這將花費大量時間。

預估的不肯定性在故事點fibonacci-like序列自己中捕獲：一、二、三、五、八、1三、20、40、100。從該序列中選擇特定數字反映了不肯定性。當不肯定性太大而沒法估計時，則可使用「?」 卡。

故事點提供了一個粗略的估計，並不能說明PBI的價值。該項目可能很是有價值，或者根本沒有增長任何價值。故事點能夠幫助項目肯定PBI的ROI（投資回報率），您能夠考慮將功能與價值一塊兒交付。

故事點與工做相關。 複雜性，不肯定性和風險是影響工做量的因素，但它們單獨使用時不足以決定工做量。

2.將故事點轉換爲小時。

經過將故事點數轉換爲小時數，您就沒法從相對估計的速度中受益。您開始以小時爲單位工做，冒着作出承諾的風險。當您將故事點的時間範圍從10-20個小時減小到15個小時時，它提供了一種錯誤的準確性。當您開始在確切的時間範圍內工做時，團隊在預估上達成一致就會很是困難。

3.平均故事點數。

在計劃撲克遊戲的過程當中，團隊的一半人預估PBI爲3個故事點，另外一半人預估爲5個故事點。只需將4個故事點做爲估算值​​，就能夠解決討論。這樣並非100%準確的，關鍵是要足夠準確，提早作好計劃。團隊不該這樣作，由於它提供了錯誤的準確性。另外，您可能會由於平均而失去一次有價值的討論。也許5個故事點是一個更好的估計。

4.在衝刺期間調整故事點對問題的估計。

當團隊開始處理問題時，即便事實證實他們的預估是不許確的，團隊也不該調整「故事點」。若是預估不正確，則它是最終衝刺速度的一部分。有時預估不正確是正常的。您不會丟失這些信息，這將成爲團隊歷史速度的一部分。

5.從不講故事的bug。

一個與當前衝刺無關的bug應該只在故事中提到，該bug是團隊須要完成的工做。若是團隊在衝刺期間保留了固定的時間來處理bug，那麼這就不適用。與衝刺中的問題相關的bug不該該用故事描述，由於這是原始評估的一部分。

6.將故事點增長到小型任務中。

調查一些關鍵的事情應該有時間限制，這件些關鍵的事情經過經驗可能只須要4個小時來完成，就無需在其中添加任何故事點了。

7.調整參考PBI的衝刺。

當一個團隊調整參考PBI的衝刺時，那麼不一樣衝刺的速度再也不具備可比性。團隊會丟失信息，您將沒法再使用歷史速度來提早計劃。最好使用一系列最新的PBI做爲參考。

8.故事再次指出未完成的問題。

將未完成的PBI移至下一個衝刺時，無需從新估計。這個估算可能不許確，但這不成問題。做爲衝刺計劃的結果，團隊將瞭解完成問題所需的全部任務。這些任務的估算以小時爲單位。所以，下一次衝刺，團隊將知道完成PBI仍須要多少時間。PBI未完成的將成爲速度的一部分。

9.由於有特定的開發人員來處理，而調整故事點估算值。

故事對應的PBI與參考的用戶故事相關，由團隊完成。團隊成員講述了PBI的故事，並在規劃會議中就估算值達成了共識。對於高級開發人員，PBI多是3個故事點，對於初級開發人員，一個PBI多是8個故事點。團隊工做量應達成協議，並將其用於計劃。您不該調整故事點，由於每一個PBI都將由特定的人來完成。也許當他們開始處理該問題時，高級開發人員正在處理生產問題。而後，初級開發人員就須要將其剩餘的工做撿起來。

10.切勿調整參考PBI。

當團隊組成發生變化時，這可能會影響速度和故事點評估。他們倆都依賴於執行工做的團隊。想象一下，當兩個高級開發人員在場時，您就能夠從故事中找到問題所在。當您要開始解決這些問題時，他們倆都離開了公司。如今，團隊中有兩個新的初級開發人員。創建一個新的用戶故事參考是很好的實踐，它須要整個團隊來進行。這樣能夠確保每一個人在講故事時都在一個步調上，並給團隊一些時間來創建新的速度。隨着團隊的愈來愈成熟，估算能力也愈來愈強，創建新的參考PBI多是一個好主意。

11.與專家保持一致。

在制定衝刺計劃時，團隊可能會與專家保持一致。解決此問題的一種方法是讓專家詳細說明這項工做，而後讓團隊的其餘成員在沒有專家的狀況下進行評估。積累特定的專業知識是不可避免的，但不要讓這削弱了團隊的估算能力。

12.在回顧會中不討論錯誤故事指向的問題。

每隔一段時間，團隊都會指出故事評估的錯誤問題，討論這些問題並嘗試瞭解這些問題很是重要的，這樣將來的評估就會更準確。在個人一個團隊中，咱們忘記了在評估時考慮測試數據的建立，所以，咱們特別討論了建立測試數據是否適用的每一個問題。若是適用，咱們會詢問他們是否考慮了測試數據的建立。這大大改善了咱們的評估質量。

結論

故事點的概念很簡單，但很難應用，幾乎每一個Scrum團隊都使用它們，但它不是官方的Scrum指南的一部分。正由於如此，人們對如何使用故事點有不一樣的見解。術語「故事點」自己已經使人困惑，由於您也能夠將它用於用戶故事之外的工做類型，在這個「點」字上，說明一個故事點表明了價值。正如一位同事指出的那樣，或許用「計劃因素」一詞來講故事點會更容易讓人理解。本文旨在幫助你們瞭解在使用故事點時可能會犯的錯誤，並以正確的方式應用它們。