另一個有關於 Velocity 的迷思，是認為 Velocity 能彰顯問題的原因。

事實上，Velocity 只能突顯出問題——預期與現實的落差，也就是交付量不如預測。但他卻無法告訴檢視者，問題出在哪。想要透過這個數據建立的圖表來找出原因是難的。

在 Scrum Team 裡，Product Owner 發現這個交付量在下跌的趨勢，透過可開發時間的趨勢線比對，排除是開發時間變少造成的，此時他也無法再往下探究。比較良性的互動可能是，Product Owner 提醒開發團隊他發現這個趨勢，確認團隊是否有意識到，並建議或許可以一起或是團隊自行透過 Retrospective 找出原因去調整。比較對立的互動，可能就是直接將下跌的原因咎責在團隊身上。

就算團隊開始透過 Retrospective 想尋找原因，只能比較質性的去探討，卻沒有其他數據可以輔助到底發生什麼事。

為什麼 Velocity 無法彰顯問題原因？我的觀點是他離造成這個結果的事件都太遠了。我畫了一張因果關係圖去示意這個情況，見下圖。

這個圖只是我簡單列舉幾個變數去繪製的，因果關係也是以我的認知去連線的，不一定是一個定論。讀者有其他不同想法、或想要再擴展的，也歡迎在留言區交流。

顏色大概是這樣的意思

• 紅色是我們關注的關鍵指標；
• 藍色是能影響指標的變數；
• 黃色則是目前會影響變數的可控制項；
• 綠色則是能影響變數的政策。

關鍵指標，通常都會是一種 Lag Measure (落後指標），透過這個因果關係，我認為 Velocity 是 Lag Measure 中，更 Lag 的那種。開始意識到 Velocity 下跌時，可能是其他早就發生的原因終於傳遞影響到這個指標上了。

我認為這就是他難以彰顯問題原因的主要原因。我甚至要比較數個 Sprint 後，才意識到整個交付量再往下滑。這真的是太慢了。

那我該如何去更快的意識到開發流動的流暢度出現問題？我會採用 Lead Time 作為參考，但如何使用等 Velocity 講完後，我會再完整的詳述。