Scrum Team 中關於插單事件的視覺化的感想

這個問題已經困擾我好一陣子了，照理來說遇到問題應該在Retrospetive 的時候討論，大家一起思考解決方案，但是如果沒辦法透過數字說話，一切流於"感覺"，容易造成發散與責難的討論。

最後想出來的解決方法在 Richard 的blog 已經整理的蠻詳盡的，實體看板的再度邂逅，插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )。

我在這邊想要補充的是，相同的問題如果不透過實體看板，想要透過電子化看板(如：JIRA) 來凸顯問題，我嘗試過的方法與侷限性，下面是我從JIRA 上收集出來的數字，每一列代表一個Sprint規劃的工作事項，而紅色框框起來的部分代表是plan meeting 後產生的新工作(issue added to sprint after start time)，這些工作可能是：

• 插單 (change feature，new feature...等)
• 營運問題排查與排解 (bug，fault...等)
• Plan 時break down story沒想清楚，新增加的task

可以看出來嚴重的時候，可能超過一半的工作都是當初沒有預期的，但是光是用 issue added to sprint after start time 可能太廣泛，沒辦法真得凸顯問題(插單/營運問題)，因為Plan 時沒想清楚後來再新增的task 有時候是必要的。

所以下圖是我嘗試以另一個維度來分析，就是task 的種類，正常來說一個sprint我們只會產生Story 然後會在Story 下開sub task，所以只要是非Stroy 型態(task，bug，fault...等)就應該是插單，所以依舊可以看出來非預期的數量很多。

電子化看板(JIRA)的好處是事後分析方便，但是sprint 發生的當下，與daily stand up meeting 卻不容易突顯出來，因為：

• 大家可能接單就順手修掉了，沒有去系統上開issue，很多是我事後要求補填的
• 電子化看板之前都專注在每個人要做什麼事，不是以Story 的角度來看，不容易凸顯問題
• 電子化看板對大家來說只是記錄工作歷程，大家只會專注在自己的工作項目，不會看到整體，通常只有team lead 或是 SM，PO會去關注。

所以直到把sprint 的工作實體看板化後，大家才正式到這個問題，好像插單真得很多，也唯有這樣才比較容易把問題講開。

另外電子化看板不容易隨時根據我們的需求去group by，而實體看辦就有這個好處，我們馬上就可以針對各種維度的問題去group by，包含：

• 哪些問題有跟PO討論過，哪些沒有?
• 哪些問題是bug，哪些不是?
• 那些是上個sprint 產生的，哪些是更久以前產生的
• 這些問題哪些是插單?
• 哪些問題是Team Lead 撿走，那些是Team member撿走

透過不同group by 的方法，就能有不同層面的檢討方式，詳情請見插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )