Foxbrush

From: http://teddy-chen-tw.blogspot.tw/2012/03/scrum-16story.html

==============================================

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

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

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

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

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

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

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

那麼估算完story point的結果已經隱含了上面這兩個story的施工先後順序，也就是說Visa信用卡付款這個story要先完成（story point為13），之後才可以實作story point為8的Master信用卡付款這個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小的值？」

***

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

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

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

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