很多團隊在執行 Scrum 時, 都會有個問題, 一個迭代中團隊要處理多少個 story 呢?
這個問題可以由這幾個面向來考慮:
(1) 團隊人數
通常 Scrum 團隊約 5-9 人. 我們來用一下簡單的數學
如果每個人處理 2 個 story, 這樣就會有 10 - 18 個 story 要處理
如果每個人處理 4 個 story, 這樣就會有 20 - 36 個 story 要處理
其實在 18 個故事時, Product Owner 應該就受不了. 一個迭代中要準備好 18 個, 這個工作量老實說不小, 不只 product owner 很累, 團隊要一起梳理很是要花很多時間.
因此, 一個團隊成員平均處理 2 個大約就是上限了
(2) 故事大小
或許故事個數大約是每個人處理 2 個故事就是上限了. 但是只看個數就好了嗎?
如果一個故事的複雜度很高, 要花到一個迭代以上的時間, 那就不太實際了.
基本上, 如果一個 story 估 10 天, 通常來說都是大於 10 天, 總是會有地方沒想到, 或者是有些 bug 要修一下. 或是要跟其他人整合需要再多發時間. 能夠比預估時間少來做完的 story, 應該是少數的案例.
一個 story 的大小, 在一開始評估時, 不應該出現太大, 至少不該接近一個迭代要花的時間, 這樣做不完的機率很大.
可是如果 story 太小, 會造成 story 個數過多, 需要花很多時間梳理.
根據網路上的經驗, 大多數的建議是大約是一個迭代的一半大小. 如果一個故事大約花一半時間就可以完成, 如果有差錯時, 還有機會可以補救.
很巧的, 這個複雜度的大小, 剛好跟前面提到的一個成員處理 2 個 story 是匹配的. 甚至可能要一個人處理 1.5 個 story 是比較保險的.
好了, 你想要在迭代中處理幾個 story 呢?
文章標籤
全站熱搜
留言列表
