Scrum 是什麼（18）：到底為什麼要估算Story Point哩？

March 22 12:54~13:50

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉
• 〈Scrum 是什麼（4）：Product Backlog〉
• 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉
• 〈Scrum 是什麼（6）：Sprint Planning Meeting 眉角〉
• 〈Scrum 是什麼（7）：Daily Scrum〉
• 〈Scrum 是什麼（8）：Sprint Review Meeting〉
• 〈Scrum 是什麼（9）：Retrospective Meeting〉
• 〈Scrum 是什麼（10）：時程估算〉
• 〈Scrum 是什麼（11）：不信邪之流程改善精神〉
• 〈Scrum 是什麼（12）：不要再用focus factor與unplanned items了〉
• 〈Scrum 是什麼（13）：為什麼不建議使用focus factor？〉
• 〈Scrum 是什麼（14）：好問題〉
• 〈Scrum 是什麼（15）：誰適合當Scrum Master？〉
• 〈Scrum 是什麼（16）：Story寫得好才容易估算(上)〉
• 〈Scrum 是什麼（17）：Story寫得好才容易估算(下)〉

 

這兩天提到story point估算的問題，剛剛在搞笑談軟工Facebook社團中，有一位鄉民問了一個很基本的問題：

幹嘛估算story point，有什麼用？

關於如何估算story point可以參考「如何估算 story point？」、「Scrum 是什麼（16）：Story寫得好才容易估算(上)」以及「Scrum 是什麼（17）：Story寫得好才容易估算(下)」。至於估算story point的原因至少有：

• 預估專案大小：假設你的團隊要開始一個新的專案，經過初估後，這個專案的story point為200。再假設你的團隊之前有實施過Scrum，依據歷史經驗平均每個sprint可以完成20個story point。此時便可「大膽假設」這個新的專案「大概需要」10個sprint左右才有可能做完。
• 觀察專案進行進度：Scrum有一個術語叫「velocity」，指的是每個sprint結束後，團隊真正完成的story point數量。藉由持續觀察每個sprint的velocity，可作為團隊是否達到穩定產出的一個指標，也可做為團隊流程改善的參考。例如，專案剛開始的前三個月，團隊的velocity只有13，經過三個月之後，慢慢每個月的velocity可以有20左右。但是，突然有一個sprint的velocity降到只有8，這樣的差異便是很值得探討的問題。團隊在retrospective meeting中便可針對此現象加以討論，是否原先對於需求大小的估計太樂觀，抑或是這個sprint臨時被抓去做了一些與專案無關的事情導致velocity降低。
• 增進團隊對於需求的了解：團隊成員在估算story point的過程中，一定會產生分歧。對於同一個story的估算，有人出20點，也有人出3點，這樣的差異是很常見的現象。藉由估算story point的過程，把團隊成員對於需求的「認知差距」突顯出來，並經過成員之間的互動與討論過程，拉近所有成員對於每一個需求的認知。

Teddy認為估算story point的所有用途中，最後一點是最重要的。因為要每一個開發人員都要估點數，因此逼著大家一定要表態。因為大家都要出牌，所以就算有人想要假死（例如每次都出問號，都說自己不知道要怎麼估），也不能再默默的假死，必須在大庭廣眾之下假死。因為估算的過程很互動且透明，所以當估算結束之後，所有團隊成員對於這個專案到底是圓的還是扁的，就有了一定的了解。這樣的了解對於團隊「接下來要做什麼」建立了一定的共識，這對於後續的開發活動能否順利的進行有著決定性的影響。所以就算是暫且不論最後估出來的每一個story的story point大小為何，以及是否能有效地反映專案大小，估算story point這樣的活動，是Scrum中很重要的一環。

***

友藏內心獨白：光記得討論如何估點，差點忘了最根本的互動這個重點。