Velocity（敏捷速度）是衡量 Scrum 團隊每個 Sprint 完成多少故事點數的核心指標。這篇文章從計算公式、圖表解讀到專案預測，帶你完整掌握 Velocity 的實務應用與常見誤區。
什麼是 Velocity（敏捷速度）？
Velocity 在敏捷開發中的定義很直接：一個 Sprint 內，團隊實際完成的故事點數（Story Points）總和。這個概念最早源自 XP（極限程式設計），後來被 Scrum 框架廣泛採用，成為 Sprint 規劃和專案預測的基礎指標。
先釐清一個常見混淆——搜尋「敏捷速度」或「敏捷度英文」時，有些人找的是運動訓練中的 agility（身體敏捷性），但本文談的是軟體開發框架中的 Velocity，兩者完全不同。
Velocity 有一個最重要的前提：它是團隊指標，不是個人績效指標。一個人寫了多少程式碼、完成了幾個任務，不是 Velocity 要衡量的事。它反映的是整個團隊在一個 Sprint 週期內的交付能力。
在 Scrum 框架中，Velocity 的位置是這樣的：Product Owner 維護 Product Backlog（產品待辦清單），團隊在 Sprint Planning 時根據過去的 Velocity 決定這個 Sprint 要承諾多少工作量，然後在 Sprint 結束時統計實際完成的點數——這就是新的 Velocity 數據。
舉個實際例子：一個 5 人開發團隊跑了三個 Sprint，Sprint 1 完成 32 點、Sprint 2 完成 28 點、Sprint 3 完成 35 點。這三個數字都是 Velocity，而且它們本來就會波動。Sprint 2 下降可能是因為有成員請假，Sprint 3 上升可能是因為團隊對技術棧更熟悉了。Velocity 的動態本質正是它的價值所在——它反映真實狀況，不是一個固定的「應該達到」的數字。
理解 Velocity 的動態特性後，下一步是搞懂它的計算基礎——故事點數。如果你的團隊在時間管理上已經有一定基礎，接下來學習故事點數的估算邏輯會更容易上手。
故事點數（Story Points）與 Velocity 的關係
Velocity 的計算單位是故事點數，所以如果團隊對故事點數的理解不一致，Velocity 就是一個沒有意義的數字。
故事點數的本質是相對估算，不是工時換算。一個 5 點的故事不代表「需要 5 小時」，而是代表「它的複雜度、風險和工作量大約是 1 點故事的 5 倍」。這個區別非常關鍵——很多團隊剛開始用故事點數時，會不自覺地把它當成工時，結果估算永遠不準。
常見的估算方法有兩種：
- 費氏數列（Fibonacci）：1、2、3、5、8、13、21。數字越大，間距越大，反映的是「越複雜的任務，不確定性越高」的現實。大多數成熟的 Scrum 團隊使用這個方法。
- T-Shirt Sizing：XS、S、M、L、XL。適合初期快速分類，但最終通常還是要轉換成數字才能計算 Velocity。
| 複雜度等級 | 費氏數列點數 | T-Shirt 尺寸 | 範例任務 |
|---|---|---|---|
| 極簡單 | 1 | XS | 修改按鈕文字 |
| 簡單 | 2-3 | S | 新增表單欄位驗證 |
| 中等 | 5 | M | 建立新的 API 端點 |
| 複雜 | 8 | L | 整合第三方支付系統 |
| 非常複雜 | 13+ | XL | 重構資料庫架構 |
實務上，大多數團隊用 Planning Poker 來達成共識：每個人同時亮出自己對某個使用者故事的點數估算，如果差異太大（例如有人出 3、有人出 13），就討論原因，然後重新估算。這個過程本身就是在校準團隊對複雜度的共同理解。
這裡有一個我們團隊實際遇過的狀況：一位新成員加入後，他對「5 點」的理解跟其他人不同——他認為 5 點大約是半天的工作量，但團隊原本的標準是「中等複雜度，可能需要一到兩天」。結果團隊重新校準故事點數標準後，Velocity 數字從平均 38 點降到 30 點，但實際產出完全沒有減少。這正好說明了：Velocity 數字的變動不等於效率變化，點數標準才是關鍵。
如果你想更系統化地學習敏捷專案管理的估算方法，可以參考 Coursera 的專案管理課程，裡面有完整的 Scrum 實務教學。
Sprint Velocity 計算方式
Sprint Velocity 的計算公式看起來很簡單，但魔鬼藏在細節裡。
核心公式：
Sprint Velocity = 該 Sprint 內所有「已完成」故事的點數總和
關鍵字是「已完成」。這裡的完成不是「差不多做好了」或「程式碼寫完了」，而是符合團隊定義的 DoD（Definition of Done，完成定義）。典型的 DoD 可能包括：程式碼已通過 code review、單元測試通過、已部署到測試環境、QA 驗收通過。如果一個 8 點的故事只完成了 80%，它的貢獻是 0 點，不是 6.4 點。這個規則看似嚴格，但它確保了 Velocity 的可靠性。
計算範例
| Sprint | 計畫點數 | 完成點數 | 備註 |
|---|---|---|---|
| Sprint 1 | 40 | 34 | 一個 8 點故事未通過 QA，不計入 |
| Sprint 2 | 38 | 37 | 接近滿額完成 |
| Sprint 3 | 42 | 39 | 一個 3 點故事因需求變更延後 |
平均 Velocity = (34 + 37 + 39) ÷ 3 = 36.7 點
建議取最近 3 到 5 個 Sprint 的平均值。太少的樣本不穩定，太多的樣本會把早期磨合期的低數據拉進來，反而不準。
承諾完成率（Commitment Reliability）
除了 Velocity 本身，還有一個很多台灣團隊忽略的指標：承諾完成率。
承諾完成率 = 完成點數 ÷ 計畫點數 × 100%
以上面的範例來算：Sprint 1 是 85%、Sprint 2 是 97%、Sprint 3 是 93%。如果承諾完成率長期低於 80%，代表團隊在 Sprint Planning 時過度承諾；如果長期高於 95%，可能代表團隊太保守，沒有充分利用產能。理想範圍是 85-95%。
新團隊的校準期
如果你的團隊剛開始跑 Scrum，前 3 個 Sprint 的 Velocity 數據不適合用來做預測。我們曾協助一個電商後台開發團隊導入 Scrum，他們第一個 Sprint 只完成了 18 點（光是搞懂流程圖和站會流程就花了不少時間），到第六個 Sprint 才穩定在 42 點左右。這段磨合期是正常的，不要因為前幾個 Sprint 的低 Velocity 就否定敏捷轉型的價值。
容量折算公式
當團隊成員請假或有人只能兼職參與時，平均 Velocity 需要做調整：
實際可用容量 = 平均 Velocity × (實際出席人天 ÷ 標準人天)
例如：團隊平均 Velocity 是 36 點，標準人天是 50 天（5 人 × 10 天），但這個 Sprint 有一人請假 3 天，實際人天是 47 天。調整後的容量 = 36 × (47 ÷ 50) = 33.8 點。這個 Sprint 的承諾上限就應該設在 34 點左右，而不是照搬 36 點。
Velocity Chart（速度圖表）如何解讀
Velocity Chart 是把每個 Sprint 的 Velocity 數據視覺化的圖表，通常是雙色長條圖：一個顏色代表「承諾點數」（計畫要做的），另一個代表「完成點數」（實際做完的）。X 軸是 Sprint 編號，Y 軸是點數。
三種常見圖形模式
穩定型： Velocity 波動在 ±15% 以內。例如平均 36 點，每個 Sprint 都在 31-41 點之間。這代表團隊成熟、估算準確、流程穩定。這是最理想的狀態，也是 Velocity 最能發揮預測價值的時候。
下滑型： 連續 3 個 Sprint 以上持續下降。這是警訊，常見原因包括：技術債累積導致開發速度變慢、關鍵成員離職、需求複雜度突然升高。看到這個模式，Scrum Master 應該在 Sprint Retrospective 中深入討論根因。
鋸齒型： 高低交替，像鋸齒一樣。通常反映兩個問題——Sprint 範疇蔓延（Sprint 進行中不斷加入新需求）或估算標準不一致。如果你的團隊出現這個模式，建議先檢查是否有「插單」文化。
Velocity Chart 與 Burndown Chart 的差異
Velocity Chart 看的是「跨 Sprint 的趨勢」——團隊的長期交付能力是穩定、上升還是下降。Burndown Chart 看的是「單一 Sprint 內的進度」——這個 Sprint 的剩餘工作量是否按計畫消化。兩者互補：Velocity Chart 幫你做長期規劃，Burndown Chart 幫你管理短期執行。
另外還有一種 Burn-up Chart（燃起圖），它跟 Burndown Chart 相反，顯示的是「已完成的工作量」隨時間增加的曲線。Burn-up Chart 的優勢是能同時顯示範疇變更——如果總工作量的線往上跳，代表有新需求被加進來。
如果你想深入了解如何運用這些圖表提升團隊的專注力與效率，建議搭配 Burndown Chart 一起使用。
實務案例
我們觀察過一個 SaaS 產品團隊的 Velocity Chart，發現一個有趣的模式：每逢季末（Q1、Q2、Q3 的最後一個 Sprint），Velocity 都會驟降 30% 以上。追查後發現原因不是技術問題，而是季末時跨部門的業務檢討會議和 QBR（季度業務回顧）佔用了大量開發時間。後來團隊跟管理層協商，把 QBR 安排在 Sprint 的前兩天集中處理，Velocity 的季末驟降問題就解決了。
用 Velocity 進行 Sprint 規劃與專案預測
Velocity 最實用的應用場景有兩個：決定下一個 Sprint 要承諾多少工作，以及預測整個專案什麼時候能完成。
Sprint 規劃的容量計算
原則很簡單：以平均 Velocity 作為下一個 Sprint 的承諾上限。如果過去 5 個 Sprint 的平均 Velocity 是 36 點，下一個 Sprint 就不要承諾超過 36 點的工作量。如果有成員請假，用前面提到的容量折算公式調整。
專案完成時間預測
預估剩餘 Sprint 數 = 剩餘 Backlog 點數 ÷ 平均 Velocity
實際範例：
- 剩餘 Backlog = 180 點
- 平均 Velocity = 36 點
- 預估還需 5 個 Sprint（如果每個 Sprint 兩週，就是約 10 週）
但這只是「基準情境」。更專業的做法是用最低和最高 Velocity 建立信心區間：
| 情境 | 使用的 Velocity | 預估剩餘 Sprint 數 | 預估時間 |
|---|---|---|---|
| 樂觀 | 最高 Velocity（42 點） | 180 ÷ 42 ≈ 4.3 → 5 個 Sprint | 約 10 週 |
| 基準 | 平均 Velocity（36 點） | 180 ÷ 36 = 5 個 Sprint | 約 10 週 |
| 悲觀 | 最低 Velocity（28 點） | 180 ÷ 28 ≈ 6.4 → 7 個 Sprint | 約 14 週 |
向利害關係人報告的正確方式
一個金融科技公司的 PM 分享過他的經驗：他從不跟利害關係人說「這個功能 10 週後上線」，而是說「根據團隊目前的交付速度，這個功能預計在 10 到 14 週內上線，最可能的時間點是第 10 週」。這種「時間窗口」的溝通方式比單一日期更誠實，也更容易建立信任。
要注意的是，Backlog 不是靜態的。隨著 Backlog Refinement（待辦清單精煉）的進行，故事可能被拆分、合併或重新估算，總點數會變動。所以預測要定期更新，不是算一次就不管了。
如果你的團隊需要更結構化的方式來管理商業目標與產品規劃，建議把 Velocity 預測整合進產品路線圖中。
提升 Velocity 的 5 個實務方法
提升 Velocity 不是叫團隊「做快一點」，而是移除阻礙團隊交付的障礙。以下是我們實際驗證過有效的 5 個方法。
1. 釐清使用者故事的驗收條件
Sprint 開始前，每個使用者故事都必須有明確的驗收條件（Acceptance Criteria, AC）。模糊的故事會導致開發過程中反覆確認需求，甚至做完才發現方向錯誤。
反面案例： 「作為使用者，我想要更好的搜尋功能」——這個故事沒有人知道「更好」是什麼意思。 正面案例： 「作為使用者，我想要在搜尋結果中看到商品圖片和價格，且搜尋回應時間 < 500ms」——這就是可驗收的。
2. 建立統一的 DoD（完成定義）
我們見過一個軟體外包團隊，開發人員認為「程式碼推上去就算完成」，但 QA 認為「測試通過才算完成」。結果 Velocity 虛高 30%，客戶驗收時大量退件。後來團隊統一 DoD 為「程式碼通過 review + 單元測試 + QA 驗收 + 文件更新」，Velocity 數字下降了，但客戶滿意度反而上升。
3. 保護 Sprint 範疇
Sprint 開始後，拒絕插單。緊急需求進下一個 Sprint Backlog，除非它真的比當前 Sprint 中的所有故事都重要（這種情況極少）。一個團隊導入「No Sprint Scope Change」規則後，Velocity 的穩定度明顯提升——從鋸齒型變成穩定型。
實務上，你可以用 ClickUp 的 Sprint 管理功能來鎖定 Sprint 範疇，系統會自動標記 Sprint 進行中新增的任務，讓插單行為可視化。
4. 定期舉辦 Sprint 回顧
Sprint Retrospective 的重點不是「誰的錯」，而是「什麼阻礙了我們完成更多？」。每次回顧至少產出 1-2 個具體的改善行動，並在下一個 Sprint 追蹤執行狀況。
好的回顧問題：
- 這個 Sprint 有哪些事情拖慢了我們？
- 哪些流程可以簡化？
- 我們需要什麼資源或支援？
如果你的團隊在回顧會議中常常陷入互相指責，可以參考領導力培養的技巧，學習如何引導建設性的團隊對話。
5. 減少技術債的累積
每個 Sprint 保留 10-15% 的容量處理技術債。如果平均 Velocity 是 36 點，就保留 4-5 點的容量給技術債相關的故事。短期看起來 Velocity 會降低，但長期來看，技術債不處理只會讓開發速度越來越慢。
（推薦試試 monday.com 的 Sprint 看板，我們團隊用它來追蹤技術債任務，設定自動化規則在技術債超過 Sprint 容量 15% 時發出提醒，避免技術債被無限期推遲。）
Velocity 的常見誤用與注意事項
Velocity 是一個強大的指標，但被誤用的頻率也很高。以下是最常見的四種誤用。
| 誤用方式 | 為什麼是錯的 | 正確做法 |
|---|---|---|
| 跨團隊比較 Velocity | 不同團隊的故事點數標準不同，A 團隊的 5 點可能等於 B 團隊的 8 點 | 只跟自己團隊的歷史數據比較 |
| 用 Velocity 評估個人績效 | Velocity 是團隊指標，拆到個人會破壞協作文化 | 用其他指標（如 code review 參與度）評估個人 |
| 強迫提升 Velocity 數字 | 團隊會降低估算標準來「達標」，數字好看但品質下滑 | 關注 Velocity 的穩定性，而非絕對數字 |
| 忽略 Velocity 波動的脈絡 | 假期、新人加入、技術轉換都會影響 Velocity | 在 Velocity Chart 上標注重大事件 |
真實案例：Velocity 膨脹的惡性循環
某公司 CTO 要求各 Scrum 團隊每季 Velocity 成長 20%。第一季，團隊開始把原本估 5 點的故事改估 8 點；第二季，故事點數標準進一步膨脹；第三季，Velocity 數字看起來成長了 60%，但實際交付的功能數量反而減少了，因為團隊把時間花在「讓數字好看」而不是「解決真正的問題」。更糟的是，技術債在這段期間爆炸性成長，因為沒有人願意把容量分配給「不會增加 Velocity 數字」的技術債處理。
這個案例的教訓是：Velocity 是溫度計，不是恆溫器。它告訴你團隊的狀態，但你不能透過操縱溫度計來改變室溫。
Velocity vs. Throughput
Velocity 計算的是故事點數總和，Throughput 計算的是完成的故事數量（不管每個故事多少點）。兩者各有適用場景：
- Velocity 適合用在故事大小差異大的團隊（有 2 點的小故事，也有 13 點的大故事）
- Throughput 適合用在故事大小已經很均勻的團隊（大部分故事都在 3-5 點之間）
如果你的團隊已經做到把大故事拆成差不多大小的小故事，Throughput 可能比 Velocity 更簡單、更實用。
對於正在經歷敏捷轉型的團隊，這些指標的選擇也是數位轉型過程中需要考量的一環。
推薦工具：追蹤 Velocity 的平台比較
選擇追蹤 Velocity 的工具時，關鍵考量是：是否內建 Velocity Chart、故事點數的支援程度、以及團隊規模的適配性。
| 工具 | Velocity Chart | 故事點數支援 | 適合規模 | 月費（NT$/人） | 免費試用 |
|---|---|---|---|---|---|
| monday.com | ✅ 透過 Sprint 看板 + Dashboard | ✅ 自訂欄位 | 5-50 人跨部門團隊 | 免費起 | 免費試用 → |
| ClickUp | ✅ 原生 Sprint 支援 | ✅ 內建 | 技術導向團隊 | 免費起 | 免費試用 → |
| Notion | ❌ 需手動建立 | 需自訂資料庫 | 預算有限小團隊 | 免費起 | 免費試用 → |
| Jira Software | ✅ 原生支援 | ✅ | 中大型技術團隊 | 約 NT$150-300 | — |
monday.com：我們團隊的首選
我們團隊實際用 monday.com 的 Sprint 看板管理日常工作。它的 Dashboard 功能可以自動彙總每個 Sprint 的完成點數，生成類似 Velocity Chart 的視覺化報表。我們特別喜歡它的自動化功能——設定一條規則：當 Sprint 結束時，自動將未完成的故事移到下一個 Sprint Backlog，並在 Slack 通知 Scrum Master。這個設定省去了每次 Sprint 結束時手動搬移任務的麻煩。免費方案不需要信用卡，適合先試用再決定。
ClickUp：技術團隊的好選擇
ClickUp 的 Sprint 功能是原生內建的，不需要額外設定。它的 Velocity Chart 可以直接在 Sprint 報告中查看，故事點數也是內建欄位。如果你的團隊是純技術團隊，ClickUp 的開發者體驗可能比 monday.com 更順手。
Notion：預算有限的替代方案
Notion 的敏捷專案管理模板可以用自訂資料庫來追蹤故事點數，但 Velocity Chart 需要手動計算或搭配外部工具。適合 5 人以下、剛開始嘗試 Scrum 的團隊。
如果你的團隊已經在用筆記軟體管理工作，從 Notion 開始是最低門檻的選擇，等團隊規模擴大後再遷移到 monday.com 或 ClickUp。
結論
Velocity 是 Scrum 團隊最核心的健康指標之一，但它的價值在於「穩定且可預測」，而不是「數字越高越好」。回顧本文的重點：
- Velocity = 一個 Sprint 內團隊完成的故事點數總和，是團隊指標而非個人 KPI
- 計算時只計入符合 DoD 的已完成故事，取最近 3-5 個 Sprint 的平均值最可靠
- Velocity Chart 的三種模式（穩定型、下滑型、鋸齒型）各有不同的診斷意義
- 用樂觀/基準/悲觀三種情境做專案預測，向利害關係人報告時間窗口而非單一日期
- 提升 Velocity 的關鍵是移除障礙——釐清故事、統一 DoD、保護範疇、定期回顧、處理技術債
下一步行動建議：如果你的團隊還沒有系統化追蹤 Velocity，今天就開始。先用最近 3 個 Sprint 的數據算出平均 Velocity，然後在下一次 Sprint Planning 時用它作為承諾上限。
想把這篇文章的方法論付諸實踐？第一步：在 monday.com 用 Sprint 看板模板建立新看板，設定故事點數欄位和自動化規則，10 分鐘就能建好你的 Velocity 追蹤系統。
Velocity 敏捷速度常見問題
Velocity 多少才算「好」？
沒有絕對標準。一個 5 人團隊的 Velocity 是 35 點，另一個 5 人團隊是 60 點，不代表後者比較厲害——他們的故事點數標準可能完全不同。真正重要的是 Velocity 是否穩定且可預測。如果你的團隊連續 5 個 Sprint 的 Velocity 都在 30-38 點之間，這就是一個「好」的 Velocity，因為你可以用它來做可靠的規劃。
新團隊第一個 Sprint 的 Velocity 怎麼設定？
不需要「設定」，而是「觀察」。第一個 Sprint 用保守的估算，承諾少一點的工作量，Sprint 結束後看實際完成了多少點——那就是你的第一個 Velocity 數據點。前 3 個 Sprint 視為校準期，不要用這段期間的數據做專案預測。
Velocity 突然下降怎麼辦？
先查脈絡，不要急著「修復」。常見原因包括：團隊成員請假或離職、Sprint 中有大量技術債需要處理、需求複雜度突然升高、外部會議佔用開發時間。在 Sprint Retrospective 中討論根因，然後針對性地調整。如果是暫時性因素（如假期），Velocity 會自然回升。
Velocity 和 Throughput 有什麼不同？
Velocity 計算的是完成的故事點數總和，Throughput 計算的是完成的故事數量。如果你的團隊已經把故事拆到差不多大小（例如都在 3-5 點之間），Throughput 更簡單直觀。如果故事大小差異大，Velocity 更能反映實際工作量。兩者可以同時追蹤，互相驗證。
敏捷速度（Velocity）和運動敏捷性訓練有關係嗎？
完全無關。本文的 Velocity 專指敏捷軟體開發框架（Scrum / XP）中的團隊產出指標，與運動訓練中的 agility（身體敏捷性）是不同概念。如果你搜尋的是運動相關的敏捷訓練，這篇文章不是你要找的內容。
可以用 Excel 追蹤 Velocity 嗎？
可以，但不建議長期使用。用 Google Sheets 或 Excel 建立一個簡單的表格（Sprint 編號、計畫點數、完成點數、平均 Velocity），搭配長條圖功能就能做出基本的 Velocity Chart。但隨著團隊規模擴大，手動維護的成本會越來越高，建議在團隊穩定後遷移到 monday.com 或 ClickUp 等有內建 Sprint 管理功能的平台。
