Scrum 是什麼（16）：Story寫得好才容易估算(上)

March 20 16:52~18:08

前情題要：

• 〈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？〉

 

某位鄉民問Teddy一個關於story point如何估算的問題，鄉民們如果曾經有將需求寫成user story的經驗，也很可能會遇到類似的問題。Teddy舉一個比較容易理解的例子來說明這個問題。假設鄉民們要開發一個電子商務網站，其中有一個「信用卡付款」的功能。客戶要求至少要支援Visa與Master這兩種不同的信用卡類型。

這樣的需求要如何寫成story？有兩種常見的寫法：

• 第一種寫法：身為使用者，我可以使用Visa與Master信用卡付款。
• 第二種寫法：把兩種不同的信用卡付款方式分開寫成兩個不同的stories。
  • 身為使用者，我可以使用Visa信用卡付款。
  • 身為使用者，我可以使用Master信用卡付款。

假設Product Owner在專案開始之前已經先把大部分的user story給寫好了，這些user story可能只有20%是比較詳細且討論估算過的，其他的user story尚未被Product Owner細分過。此時Product Owner想找開發人員來初估一下每一個user story的story point，以便大致上了解整個計畫的總story point（初估專案大小）。假設Product Owner將上面這個信用卡付款的需求寫成第一種寫法的樣子（在同一個user story中同時實做完成Visa與Master信用卡付款），而開發人員估算這個story的story point為20。到目前為止都沒有問題，但是，如果Product Owner將這個需求採用第二種寫法寫成兩個stories，那麼這兩個stories的story point要怎麼估算？

在這個問題上面，開發人員的意見分成兩派，以下以全真派和古墓派作為區隔。全真派的開發人員認為這兩個user story的大小是一樣的，所以認為應該賦予它們一樣的story point，例如13。但是古墓派的人認為，信用卡付款的需求雖然被細分為兩個不同的user story，但是這個兩個user story有一些共同的功能，如果先做完Visa信用卡付款這個story，那麼Master信用卡user story所需要做的事情就比較少，所以在估算story point時，後者的story point應該比前者要小。古墓派的這種講法聽起來很合理，對不對？

對，但是這又衍生了另外一個問題，假設最後估算的結果如下（括號內的數字表示story point）：

• 身為使用者，我可以使用Visa信用卡付款（13）。
• 身為使用者，我可以使用Master信用卡付款（8）。
  

那麼估算完story point的結果已經隱含了上面這兩個user story的施工先後順序，也就是說Visa信用卡付款這個user story要先完成（story point為13），之後才可以實作story point為8的Master信用卡付款這個user story。但是，這樣的相依性如果日後大家都忘記了，當專案正在執行的時候，Product Owner先選了Master信用卡付款這個story來施工（story point為8）。等到下一個sprint，Product Owner要選Visa信用卡付款這個story時，突然鬼遮眼問了開發人員這樣一個問題：「上個sprint不是已經做過Master信用卡付款這個story，該story的story point只有8，那為什麼接下來要做的Visa信用卡付款這個類似功能的story，它的story point反而是13呢？是不是應該要重估一次，改成比8小的值？」

***

把一個比較大的user story切割成若干個相依的小user story，就容易出現上述這種很討厭的問題。將user story以下面的方式重寫是一個可能的解法：

• 身為使用者，我可以使用「第一種」信用卡付款（13）。
• 身為使用者，我可以使用「第二種」信用卡付款（8）。

用類似「變數宣告」的方式來表示這個系統會提供兩種不同的信用卡付款方式，至於是那兩種這兩個user story並沒有明確的寫出來。但是因為在user story中有註明「我可以使用第一種信用卡付款」與「我可以使用第二種信用卡付款」，所以在挑選user story的時候，很明顯的一定會做story point為13的「第一種信用卡付款」這個user story。至於等到真正實作的時候，這個「第一種信用卡付款」是Visa或是Master，就由Product Owner依據實際的狀況來決定。

上面提到的這種user story撰寫方法是不是最好的方式，說真的Teddy並不知道，但至少是一個看起來還可以接受的方式。

***

下一集：〈Scrum 是什麼（17）：Story寫得好才容易估算(下)〉

***

友藏內心獨白：Product Owner真的很重要。