前一篇文章，我提到來自 PO 與 QA 的兩個張力-舒緩系統，是主管/ Scrum Master 下手調整團隊系統的契機。解決根源性問題，我們應該創造的系統，必須包含兩個特質：

• 透明化專案推進狀況
• 降低出錯率

進行邏輯回推，可以發現源頭都是一樣的：

如果我們從使用者故事出發，把上圖的方向反轉：

我們得到了一個 Scrum 框架的線索。因此，我了解到，兩個團隊在規畫階段 (Refinement & Planning) 與執行階段 (Daily)，出了某些問題，導至了後來的狀況。所以，從「規畫階段」下手，是符合邏輯的起手式。

在軟體業(或任何產業)，常有的一個迷思：花時間做計畫，很浪費資源。在我的工作經驗中，常會聽到一句話：「這麼人聚在一起討論，很貴，大家要加快速度。」這等同於一個心理暗示，開會等於浪費時間，增加成本支出。事實真的是這樣嗎？

來做個簡單的成本計算：會議成本 = 與會人數 x 平均時薪 x 開會時間。在易於觀察的團隊會議中，精於計畫的主管和 PO 很容易就會有成本正逐漸墊高的憂慮。而在實務上，一個規畫不足，討論不充份的開發，成本的浪費是在執行階段的等待、討論與重構，但由於這些事件的發生的時間與空間是離散的，幾乎是不可能有全面的觀察與記錄，成本的計算也就不全面，如下圖，未被觀測到的事件造成的成本，成了容易被忽略的「隱形成本」。

而這個觀測上的偏差，導至了規畫時急急忙忙，執行時跌跌撞撞。為了彌補規畫階段的不足，加班追趕進度成了必要手段，公司不心疼加班費，反而覺得團隊好拼，好認真。是不是挺荒謬的？

我的信念是：投資妥善且有效率的規畫，可以節省實作混亂造成的成本浪費。在 Scrum 中的規畫階段，就是 Refinement 與 Planning 兩個活動。團隊若缺乏有關於這兩個活動的實踐指導，就會缺乏有效率的產出與結論。下一篇文章，我們就來聊聊，如何進行有效率的「規畫」。