減輕敏捷實戰中故事點發生漂移的風險 - modernanalyst

作為潛在的客戶，我希望能夠根據輸入的搜尋條件檢視書籍。

使用者故事不僅是有效的需求管理工件，而且對於估計專案的範圍/規模以及跟蹤團隊的進度也至關重要。在確定專案規模時，團隊會估算完成每個使用者故事所需的工作水平，然後彙總其結果以得出對專案範圍的估算（有關如何估算敏捷工作水平的更多詳細資訊）專案，請參閱Mike Cohn 關於該主題的出色著作）。
 
敏捷團隊通常會使用一種稱為故事點的無單位量度。使用故事點的優點是它們的內在價值是相對的。故事點不會嘗試得出通常與時間相關的絕對值（例如，完成特徵X需要多少天），而是隻關注故事相對於其他故事已經或需要完成的相對工作量或複雜性。將專案的故事點總數與團隊的速度（每個迭代週期完成的故事點數）相結合，專案涉眾就可以越來越準確地瞭解專案的規模以及所需的時間。完成當前的團隊。

什麼是故事點 
最初，當團隊形成時，他們將估計一些基準故事的故事點。例如，團隊可能將以下三個故事作為其基準：

• 作為使用者，我想按主題瀏覽書籍集：8分

• 作為使用者，我希望能夠儲存我的付款資訊：2分

• 作為使用者，我希望能夠向人們推薦我最喜歡的書：5分

故事點漂移
使用故事點時存在的潛在風險之一就是我所說的“故事點漂移”。故事點漂移是指在專案開始時具有給定故事點值的使用者故事比專案後期具有相同故事點值的故事需要更多或更少的工作，而完成故事所需的工作量是給定的。
 
例如，假設我在專案稍後估計了以下使用者故事：

• 作為使用者，我希望能夠將我的銀行帳戶連結到我的登入名並設定每月提款計劃：8分

• 作為使用者，我希望有一個主題編輯器可以自定義我的線上會員商店的外觀：5分

• 團隊的集體記憶是短期的：團隊開始估計新故事時，通常會借鑑最近完成的故事中的經驗。如果其中一些故事被錯誤分類（要麼比故事點估計中所代表的需要付出或多或少的相對努力），然後團隊最終就可以相信這些最近的故事是故事點和使用價值的新規範。這些都是將來的參考，它們使原始基準參考的故事點值出現了偏差。

• 團隊的互補性已經改變：專案團隊隨時間變化的情況並不少見。我注意到，即使團隊規模越來越大，團隊的速度似乎也保持恆定。在調查此問題時，我發現通常是因為團隊開始以較少的分數來估算故事，因為由於現在有更多的人要從事該專案，他們現在認為故事“更容易”。結果，以前可能被認為是8分的故事現在估計為5分。結果，儘管事實是團隊可能會因估計偏差而做得更多，但團隊的速度似乎沒有變化。

• 沒有提及基線：敏捷專案通常透過最小化不會導致客戶價值的間接費用以及適應非理想情況而蓬勃發展。例如，敏捷團隊很少等待每個人參加會議-會議是有時間限制的，無論錯過了誰，會議都會準時開始和結束。但是，有時敏捷團隊可能會忘記將諸如參考故事之類的物理物件帶到會議中。有時，團隊會根據回憶而不是實際參考來嘗試透過會議。如果沒有實際的參考故事和點值，則得出的估計值可能會有些偏斜。

 如何減輕故事點飄移
當我看到故事點漂移時，它隨著時間的推移以很小的增量發生了–您直到幾個月後才意識到估算值有很大的偏差。故事點漂移會導致資源計劃，進度和完成時間估算方面的問題。以下是一些我用來幫助減輕故事點漂移的策略：

• 將原始故事和最近故事的混合作為新估計的基準：進行相對比較時，保留原始估計不會有什麼壞處。舉一些最近的例子也很有幫助，特別是因為您的初始估計可能僅適用於一些潛在的故事點值。在討論分配給新故事的估算級別時，或者在計劃撲克的過程中陷入僵局時，每個可能的故事點值具有1或2個故事也可能會有所幫助。

• 瞭解實施後何時應該重新估計某些故事：每隔一段時間，您會遇到一個故事，它比您最初想的要花費更多（或更少）的精力。如果付出的努力水平與另一個獲得相同分數的故事完全不同，則您可能希望重新評估該故事，以免影響團隊對一定數量故事價值的理解。通常，只有在一個專案進行了多個Sprint計劃後，我才會重新估算一個故事–早期，您可能會發現許多故事所花費的精力比您想象的要少或多，並且您很想調整這些故事的大小。但是，只要故事的相對數量是相同的努力，那麼就無需重新估算。因此，如果您認為3點故事需要一天的時間才能完成，而一週中大部分時間都用完，請檢視5點和8點故事的表現。如果這些花費的時間也比預期的長，請不要重新估計。

• 每隔幾個Sprint花費一點時間並分析相關故事： ScrumMaster或專案經理可以隨時檢視一些已完成的故事，以尋找可能的故事點漂移。如果發現漂移，請與團隊合作，看看他們的想法。如果團隊同意，則從相對的努力上重新估計似乎超出預期的故事。