如何估算 story point？

5/03 22:29 5/04 00:30

前幾天實驗室學弟問了 Teddy 一個在 Scrum 中如何估算 story point 的問題，在此 Teddy 談一下自己曾經試過的兩種估算方法。首先假設 Scrum 團隊有四個開發人員，每一個 sprint 長度為兩週 (10 個工作天)。

方法一

【2015/05/26】方法一已不建議使用，請直接看方法二。原因請參考〈Scrum 是什麼（13）：為什麼不建議使用focus factor？〉。

首先將 1 個 story point 定義為『一個理想的工作天 (八小時)』。在估算Story 與 Task 的時候採用相同的單位 (也就是都以 story point 估算來估算)，並使用 focus factor 來調整團隊實際可貢獻於專案的時間。

這個方法是 Teddy 從《 Scrum and XP from the Trenches》這本書學來的，在 sprint planning 開始的時後，要知道這個 sprint 可以挑多少 story 出來做，首先就要估算這個團隊可用的 story point。估算方法如下：

開發人數 x 可以獲得的工作天數 x focus factor

在一個四個開發人員，sprint 長度為兩週的專案裡 (沒有人請假，如果有人請假要扣掉請假的天數)，可以得到

4 x 10  = 40, 也就是說理想上這個團隊有 40 個 story points 可以使用。也就是說，理論上這個團隊可以完成 40 個 story points 的需求。

但是大家都知道，不可能一天 8 個小時都在從事開發工作，有時候要開會，回 e-mail，MSN 打屁一下，泡杯咖啡，上廁所，吃下午茶等等。有時候要回答客戶問題，或是應付老闆三不五時丟出來奇怪的要求。也可能公司環境太吵或是在大熱天冷氣突然壞掉，害你無法專心寫程式。有太多因素造成實際上不可能達到 40 story points 這個『理想值』。所以，就必須要把這個理想值打個折，至於要打幾折的這個數字，就叫做『focus factor』。focus factor = 1 就表示理想值 (買東西不打折)，facus factor = 0 就表示沒有任何生產力 (買東西不用錢啦)。當然 1 和  0 應該都是不合理的數值，至於這個值應該要給多少，每個團隊不一定，總之概念上就是 focus factor 越高表示團隊專注力越高，也就是大部分的時間都可以用來從事 sprint planning 所規劃的開發活動。對於一個剛開始採用 Scrum 的團隊，可以選用 70% 左右的值。

所以，我們得到了 40 * 0.7 = 28 (story points)

接下來假設  Product Owner  挑選了 A, B, C, D, E 這五個 stories，團隊成員估算出這五個 stories 的 story point 分別為：

A : 8 story points   ......8
B : 5 story points   ......13
C : 13 story points ......26
D : 3 story points   ......29
E : 5 story points    ......34

由於團隊預計只有 28 story points 可以使用，如果要完成 A-D，則需要 29 story points，因此如果保守一點那麼這個 sprint 就只會挑出 A-C (26 story points) 這三個 stories 來施工。當然此時 Scrum Master 也可以詢問團隊成員，是否有信心可以完成 A-D，如果大家都覺的 ok，那麼也可以挑選 A-D 。

假設我們保守一點選擇了 A-C 這三個 stories，接下來就是將 story 細分，列出完成每一個 story 所需的 tasks (task 才是真正的施工內容)。典型的 task 有：寫 acceptance test cases， 設計物件，設計介面，設計資料庫，coding，unit testing，寫文件等等。基本上估算 task 所使用的單位應該是『小時』。但是由於 story point 是沒有單位的 (當然你可以用 1 story point = 8 hours 這種『匯率』來換算)，如果估算 story 用 story point，而估算 task 用 hour，那麼團隊成員會不自主的去換算，造成估算困擾，因此有一種簡單的方法就是 task 也用 story point 估算。

舉個例子，假設 Story A 是 8 story points，經過 task breakdown 之後團隊列出了以下幾個 tasks：

• Write acceptance tests: 8 hours (1 story point)
• Design UI: 8 hours (1 story point)
• Write UI code: 13 hours (1.625 story point)
• Write DAO code: 13 hours (1.625 story point)
• Write DAO unit tests: 8 hours (1 story point)
• Test: 5 hours (0.625 story point)

Task 所需時間加起來 55 hours = 6.875  story points。這時候你會想，ㄟ (馬總統上身)，剛剛估算 Story A 是 8 story points，但是實際列出完成這個 story 所需的 tasks 只需要 6.875 story points，那麼是要把 Story A 改成 6.875 story points，還是增加 task 所需的時間，想辦法把 task 的總時間也變成 8 story points？不知道鄉民們在剛開始嘗試 Scrum 時會不會有類似的困擾？Teddy 剛開始採用 Scrum 時是有這樣的困擾，也嘗試過三種修正方案：

1. 不理他，還是用原本估算的 Story 所得到的 story point 來作為這個 sprint 可以完成多少 stories 的依據。
2. 不理他，但是改用所有 task 加總的時間來作為這個 sprint 可以完成多少 stories 的依據。
3. 改用 bottom-up 的方式來估算一個 Story 的 story point。也就是說，先不估算 A, B, C, D, E 的 story point，而是直接做 task break down，然後把每一個 story 的 task 的加總作為該 story 的 story point (有點繞口)。

先講修正方案三，這種方法開發人員很容易了解，但是其實是不太符合 Scrum 精神。因為原本估算 story point 的目的是用來評估不同 story 之間的『相對大小』，並不是要得到一個精確的數值說 Story A 是 6.25 story points，Story B 是 5.125 story points ...。先估算 task 然後再把 task 加總的時數換成該 Story 的 story points 看起來很合理也比較『精確』，但是卻完全失去了原本估算 『Story 相對大小』的精神，而且還會引伸出『當實際施工時，發現原本估算的 task 時間不準，那麼是否要重新調整 Story 的 story point 這類的問題』 。

***

後來 Teddy 上過 Certified ScrumMaster 課程之後，慢慢體會修正方案二應該是比較好的方法，這也衍生出 Teddy 在這邊要介紹的第二種方法：

方法二

估算 Story 採用 story point，估算 Task 採用小時。Story point 本身沒有單位，每一個 Story 的 story point 是採用『相對大小』來估算的，不用拘泥於 1 story point = 8 hours 這樣的單位換算。至於每個 sprint 可以完成多少 stories，則是以 task 加總的時數來計算。

在 sprint planning 開始的時後，要先計算團隊在這個 sprint 可用的『工作時數』，計算方法如下：

開發人數 x 可以獲得的工作天數 x 每日工作小時

在一個四個開發人員，sprint 長度為兩週的專案裡 (沒有人請假，如果有人請假要扣掉請假的天數)，可以得到

4 人 x 10  天 x 一天工作時數 (5 小時) = 200 小時

這邊雖然省略了 focus factor，直接填入團隊(平均)每天可實際投入開發的時數，當然這個時數也是打過折的，所以效果和 focus factor 是類似。Teddy 曾經在某本書中 (忘了哪一本了) 看到一個員工平均一天可以有 5 個小時不受干擾的工作時間就已經很不錯了，因此後來 Teddy 都直接用 5 個小時來估算團隊可以投入的時間。

得到了預計可以投入的工作時數之後，其他的步驟就和 Teddy 在方法一中所說得很類似了，只是這個 sprint 可以完成多少 stories 是在估算 task 階段才決定的。以剛剛的例子：

A : 8 story points   ......8
B : 5 story points   ......13
C : 13 story points ......26
D : 3 story points   ......29
E : 5 story points    ......34

當估算完 Story 的 story points 時，這時候還不確定可以完成多少個 stories。假設經過 task breakdown，得到完成這些 stories 所需的時間為：

A : 55 hours       ....55
B : 16 hours       ....71
C : 48 hours       ....119
D : 22 hours       ....141
E : 25 hours       ....166

結果發現雖然 A-E 的 story points 為 34，但是實際施工預估時間卻只要 166 小時，所以在這個 sprint 除了可以完成 A-E 之外，還可以再選新的 story 進來。

鄉民甲：為什麼 Story A (8 story points) 需要 55 小時，而 Story C (13 story points) 明明比 Story A 要大，卻只要 48 小時？是不是代表 Story C 的 story points 要重估？

Teddy 回答：不需要。再強調一次，Story 的是估算彼此之間的『相對大小』，例如，你要做使用者新增，查詢，刪除，修改這四個 stories。團隊成員認為這四個 stories『大小』是差不多的，因此都估 5 story points。假設你在 Sprint 10 先完成了『新增』這個 story，由於這是這系列的第一個 story，你需要設計資料庫，所以你花了 35 小時，但是後面三個 stories 並不需要設計資料庫，你可能分別花了 28, 25, 31 小時。實際施工所花的時間會受到很多因素影響，例如認領工作的人對於該工作的熟悉度，是否在該工作中使用到新的技術，不確定性的高低，發生難解的 bugs，生病或是和男女朋友吵架導致精神不佳等等。但是這並不代表『Story 的大小改變了』，所以不需要因為 task 預估或是實際花費的時間來修改 story points，除非當初估算 story 的相對大小估錯了。

再舉個日常生活的例子。老師叫學生去操場拔草，小胖身強體壯，『預估』只要 1 小時就可以拔完。如果是換成瘦小體弱的小英，則『預估』需要 3 小時。同樣一個 Story (操場拔草)，小胖 1 個小時可以做完，小英需要 3 小時，我們需要重估這個 Story 的『大小』嗎？當然不需要，因為操場裡面的草，不會因為要去拔它的人不同而有任何改變。所以，只要在估算所有 story 時採用『相對大小』的方式來預估，那麼就不需要因為『預估』所需完成該 story 的 task 時間或是『實際完成』的 task 來重新調整 story point 了。長此以往，團隊還是會得到一個穩定的 velocity (每一個 sprint 實際完成的 story points)。

***

友藏內心獨白：以上來賓言論不代表本台立場。