速度的定義#
速度（Velocity）是團隊在一個迭代中實際完成的 Story Point 總數。只有完全完成（通過驗收測試）的 Story 才計入速度。
部分完成的 Story 不計入速度。如果一個 5 點的 Story 做了 80%，速度貢獻為 0，而非 4。這能防止團隊高估自己的產出。
計算速度#
速度的計算很簡單：
- 迭代結束時，列出所有已完成的 Story
- 加總這些 Story 的點數
- 這個總和就是該迭代的速度
利用速度做規劃#
速度讓團隊能夠回答以下問題：
- 「這個版本什麼時候可以完成？」——用剩餘 Story Point 除以平均速度
- 「到期限為止我們能完成多少？」——用剩餘迭代數乘以平均速度
使用最近 3-4 次迭代的平均速度作為預測基準，比單看最近一次更穩定。
影響速度的因素#
速度會因為多種原因而波動：
- 團隊成員的增減
- 技術債務的累積
- 新領域的學習曲線
- 假期和請假
- 估算技巧的改善（估算更準確後，速度數字會趨於穩定）
速度的正確使用#
速度是規劃工具，不是績效指標#
絕對不要用速度來比較不同團隊的生產力，也不要用速度作為績效評估的基準。不同團隊的 Story Point 定義不同，速度沒有跨團隊的可比性。這樣做只會導致團隊灌水（story point inflation）。
追蹤速度趨勢#
- 速度穩步上升：團隊正在磨合和進步
- 速度穩定：團隊運作正常
- 速度持續下降：可能有問題需要調查（技術債、士氣、干擾等）
Figure 11.1: Planned and actual velocity after the first three iterations
Figure 11.2: Plotting cumulative planned and actual story points
監控工具#
常見的速度監控方式：
- 燃盡圖（Burndown Chart）：展示剩餘工作隨時間的變化
Figure 11.3: An iteration burndown chart
Figure 11.4: Burndown chart for the project in Table 11.2
Figure 11.5: A daily burndown chart
Figure 11.6: Estimates are written, and frequently revised, on a whiteboard
- 速度歷史圖：展示每次迭代的速度趨勢
- 發布燃盡圖：展示剩餘 Story Point 在多次迭代中的消化趨勢
簡單的燃盡圖就足以應付大多數團隊的需要。不需要複雜的專案管理工具——一張白板就夠了。