Scrum 系列：如何才能正確理解與應用 Team Velocity 圖表？
Scrum 中的 Team Velocity 是指團隊在一個 sprint 中完成的工作量，通常以完成 PBI 的總點數或數量來衡量。Team Velocity 可以幫助團隊預測未來 sprint 中能夠完成的工作量，這有助於規劃和預測發布日期，並促進持續改進。
有一天，一位朋友私訊我說：「我以前在使用 Jira 的 Team Velocity 時，只有 Commitment 和 Completed 兩個分類，非常清晰易懂。但現在在使用 Azure DevOps 的 Team Velocity 時，卻有四種分類，讓我感到很困惑，這到底是怎麼回事？」
我回答說：「第一次使用 Azure DevOps 的 Team Velocity 時，確實會讓你感到有些複雜。一旦你理解了圖表的設計原理，你就能更仔細地觀察團隊如何運用 sprint。」
因此，在本篇文章中，我們首先將一起了解圖表的四個主要分類；接著，透過進階的設定，幫助我們將 Team Velocity 圖表調整成更符合團隊 sprint 使用的方式；最後，我們將探討一些三個常見的壞味道。
圖表解讀
我們以 Azure DevOps 中的 Team Velocity 圖表為範例。如果沒有搭配相關的需求管理方法，這可能導致圖表失去意義。要使圖表具有解讀性，必須調整 sprint 的起始日期為 sprint planning 舉辦的日期，並將預計完成的 PBI 移至該 sprint 中。
從下圖中，可觀察到 sprint 1 到 sprint 7 的設置和管理並不恰當，導致圖表缺乏可解讀的數據。然而，在 sprint 8 之後，團隊正確使用 sprint 工具，使得圖表開始呈現出有意義的數據。
當數據呈現正確時，每個 PBI 會根據其所處的狀態被歸類為四種分類之一。下面對這四種分類進行解釋：
Planned（已規劃）
在 sprint 開始時，計算 sprint 中 PBI 的總點數，在 sprint 中以「淺藍色」呈現這些完成和未完成 PBI 的總點數。
Completed（已完成）
在 sprint 結束時，計算 sprint 中完成 PBI 的總點數，在 sprint 中以「深綠色」呈現這些完成 PBI 的總點數。
Completed Late（已完成但延遲）
在 sprint 中規劃要完成的 PBI，由於意外的原因造成這些 PBI 在未來的 sprint 中完成。如果這些 PBI在過程中沒有更新成未來的 sprint，在原來的 sprint 中會以「淺綠色」呈現這些完成 PBI 的總點數。
Incomplete（未完成）
在 sprint 中規劃要完成的 PBI，由於意外的原因造成這些 PBI 到目前為止都還沒完成。如果這些 PBI在過程中沒有更新成未來的 sprint，在原來的 sprint 中會以「深藍色」呈現這些未完成 PBI 的總點數。
進階設定
在 Team Velocity 圖表的進階設定中，可以做更多細膩的參數設定。
Velocity
當團隊有做估算時，我們會將點數記錄在 PBI 中的 Effort 欄位，因此，我們就可以設定成「Sum of Effort」；如果團隊沒有做估算，我們可以設定成「Count of work items」。
Number of iterations
為了要追蹤 Team Velocity 的長期趨勢與變化，可以將這個值設定成最大值。目前系統允許的最大值為 15，表示可以追蹤最近 15 個 sprint 的數據。
Display planned work for iterations
sprint planning 發生在 sprint 的第一天，但是偶爾會忘記把 PBI 放進 sprint，或是團隊成員臨時增加新的 PBI。
實務上，我們通常會把在第二天以前移動到 sprint 的 PBI 都視為已規劃 PBI。所以，我們可以把這個參數設定成 1，避免低估已規劃的工作量。
Highlight work completed late
在預設的情況下，無論多久以後完成的 PBI，都會在原本的 sprint 中歸類成 Completed Late。但是這樣的使用方式是不合理的，等於我們沒有在 sprint 結束時，認真思考未完成的 PBI 應該放回 Backlog 中還是移動到下個 sprint。
因此，通常我會設定成一個不會太大的數字。當此參數設定成 3，表示在 sprint 結束的三天內，都可以歸類到這個 sprint 的 Completed Late；如果超過三天才完成的 PBI，就不會計算到 Completed Late 中。
壞味道
Planned PBI 和 Completed PBI 差距太大
一個優秀的團隊通常具備較佳的規劃能力，能夠在 sprint 開始時合理預測團隊大約可以完成多少工作量。根據上圖中的 sprint 8 到 sprint 14 可以觀察到，每個 sprint 的 Planned PBI 總點數和 Completed PBI 總點數是接近的。
然而，在一個初期導入 Scrum 的團隊中，常常會發現 sprint 的 Planned PBI 總點數遠高於Completed PBI 總點數。這意味著團隊目前暫時無法準確估計自身能夠完成的工作量，因此高估了團隊可以實際完成的總點數。
一般會建議 Planned PBI 總點數和 Completed PBI 總點數差距在 20% 內，主要是因為在軟體開發的過程中會遇到一些不預期的情況，有時候規劃的 PBI 比較多，完成的 PBI 比較少；有時候規劃的 PBI 比較少，完成的 PBI 比較多。只要兩者大致上差不多即可。
每個 sprint 的 Completed PBI 總點數不穩定
一個優秀的團隊通常具備較穩定的交付能力，因此每個 sprint 的 Completed PBI 總點數都差不多，有時稍高，有時稍低，但波動不會過大。
在上圖中可以仔細觀察 sprint 8 到 sprint 14，會發現 Completed PBI 總點數大約在 60 到 80 之間，近三個 sprint 甚至略有增加。若細究，會發現 sprint 11 稍微下降，此時可利用圖表檢視團隊在該 sprint 中是否有任何問題需進一步改進。
若發現團隊每個 sprint 的 Completed PBI 總點數不穩定，波動極大，這是一個壞味道，表示團隊的工作模式不穩定，有大量改進的空間。
充斥許多的 Completed Late PBI 和 Incomplete PBI
如果在 Team Velocity 圖表中觀察到大量的 Completed Late PBI 和 Incomplete PBI，這顯示團隊未充分善用 sprint 這個工具。
舉例來說，若某個 PBI 在 sprint 8 被安排，但直到 sprint 10 才完成，圖表上的 sprint 8 將顯示出淺綠色的 Completed Late。然而，這樣的情況並不合理。假設現在時間是 sprint 10，通常我們會專注於檢視 sprint 10 的 taskboard，而不會特意返回 sprint 8 的 taskboard。因此，這個 PBI 很容易在我們團隊的視野中消失，成為一個被忽略的 PBI。
在觀察到此現象後，團隊在 sprint 8 和 sprint 9 進行調整，改變 sprint planning 的方式。在每次 sprint planning 開始時，團隊首先檢視前一個 sprint 未完成的 PBI 應該如何處理：是移到回 backlog 還是移到下一個 sprint。隨著團隊採取這種做法，可以發現在 sprint 10 之後，淺綠色的 Completed Late PBI 不再出現。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
