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」我,讓我提供更多的優質文章給你。