Scrum 是什麼（12）：不要再用focus factor與unplanned items了

February 02 13:37~14:58

 

前情題要：

• 〈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）：不信邪之流程改善精神〉

 

不曉得有多少鄉民跟Teddy一樣都是讀《Scrum and XP from the Trenches: How we do Scrum》這本書 長大 來學習Scrum的。這本書寫得很好，但是書中有兩個做法，focus factor與unplanned items，經過Teddy實際實施過後的經驗，再加上2009年去上Certified ScrumMaster課程時親自詢問授課講師所得到的答案，Teddy會建議不要使用。

關於focus factor的解釋請參考「如何估算story point？」這篇，Teddy今天想談的是unplanned items。

這一切的一切，還是要從某鄉民兩個小時之前在Facebook上與Teddy的對話說起：

鄉民：關於bug的問題，如果是外面的人發現的bug，要算在下一個sprint的task嗎?

Teddy：這要看Product Owner如何安排。

鄉民：我們是在當下的sprint加入一個fix bug task，所velocity會變低。

Teddy：我以前儘量不會一收到bug report就馬上去改它，而是會在某個sprint安排一個bug fix的story, 裡面包含所有要fix的bug。這個修bug的story也是要估算story point的，所以不會有作了task但是導致velocity降低的問題。

鄉民：可是如果bug fix task算unplanned item的話，就不算在velocity裡了說。

Teddy：我之前去上Certified ScrumMaster課的時候，上課講師告訴我，任何的task一定要歸屬某一個story。所以我上過課之後，就把unplanned item給取消了，不再採用了。

鄉民：有這種事...

***

Unplanned item就是在sprint planning meeting中沒有被規畫到的工作都可以放到這裡面的某種容器，採用unplanned item有幾個目的：

• 應付需要立即處裡的突發狀況：例如使用者臨時回報需要立即修復的重大的bug，修這個bug的task沒地方貼只好把它放在所謂的unplanned item這的分類裡面。
• 不先完成不行的工作：例如，開始實作某個story的時候發現需要先修改另一個既有功能否則做不下去；或是要先安裝一個測試環境才可以完成整個story。

一個sprint的unplanned item數量越多，的確會造成團隊的velocity（每個sprint實際完成的story point稱之為velocity）下降。有人覺得這是採用unplanned item的好處，因為當團隊的velocity下降，在retrospective meeting時團隊就應該要檢討原因並訂出改善的方法，以便日後慢慢減少每個sprint發生unplanned item的次數。但是很多人可能會把unplanned item當成一個「後門」，反正就算是sprint planning meeting忘了列出的工作到時候只要丟到unplanned item就好了，或是忽略品質的重要性，想說反正有人回報bug就丟到unplanned item就好了。

拿掉unplanned item其實會讓整個Scrum的流程變得比較簡單（原本的Scrum其實根本沒有unplanned  item這種東西），也可以強迫團隊重視流程的問題。例如：

• 應付需要立即處裡的突發狀況：與其反射性地將所有接收到使用者回報的bug立即放到unplanned item中修正而搗亂了原本開發的步驟，拿掉unplanned item之後團隊會先思考，這個bug如果可以等到下個sprint在處裡，那就不要現在立即處理。如果真的一定要立即處理，可以選擇：
  • 寫一個bug fix task然後把這個task貼到某個story裡面（通常是較要性比較高的story這樣才會優先被施工）。
  • 如果修這個bug很花時間，或是需要好幾個task才可以修完，可能需要考慮新增一個story。雖然Scrum強調「sprint開始之後儘量不要調整story」，但是如果遇到非處裡不可的情況還是應該要隨機應變一下，可以把重要性比較低的story暫時移除讓bug fix的story插隊一下。
• 不先完成不行的工作：看看這些沒被規畫到但是又非得完成的task和哪一個story有關，就貼在那個story上面。

總之，每一個task一定要屬於某一個story就對了。

***

看到這邊鄉民們可能會說，這樣子不是換湯不換藥嗎？不管有沒有unplanned item這個分類，這些未被規劃的工作還是會讓velocity降低啊。沒錯，這就是重點：

• 如果團隊的velocity經過好幾個sprint之後都還不能穩定下來，就表示某種警訊。還記得Teddy說過「Scrum 本身不能幫你解決問題，但是可以幫你把問題暴露出來」，問題既然暴露出來了，團隊就需要找出問題並謀求改善之道。
• 既然有沒有unplanned item這個分類都可以把問題暴露出來，那當然是拿掉unplanned item這個分類會比較簡單啊。

***

下一集：〈Scrum 是什麼（13）：為什麼不建議使用focus factor？〉

***

友藏內心獨白：古人有云：盡信書不如無書。