燃盡圖（Burndown Chart）是 Scrum 團隊追蹤剩餘工作量與時間關係的折線圖，能即時預警進度風險。這篇指南涵蓋燃盡圖的定義、四大類型、建立步驟、走勢判讀，以及適合台灣團隊的工具推薦。
什麼是燃盡圖（Burndown Chart）？
燃盡圖是一張用視覺化方式呈現「剩餘工作量 vs. 剩餘時間」的折線圖。它最早由 Scrum 框架的共同創始人 Ken Schwaber 推廣，現在已經是敏捷團隊最基礎的進度追蹤工具。
核心邏輯非常簡單：圖上有兩條線。
- 理想燃盡線（Ideal Line）：從 Sprint 開始時的總工作量，直線下降到零。這是「如果一切按計畫進行」的理想軌跡。
- 實際燃盡線（Actual Line）：每天根據真實剩餘工作量更新的曲線。它和理想線的差距，就是你的進度健康度。
當實際線在理想線上方，代表進度落後；在下方，代表進度超前。就這麼直覺。
燃盡圖與燃起圖（Burnup Chart）常被混淆——燃盡圖追蹤「還剩多少沒做」，燃起圖追蹤「已經完成多少」。兩者方向相反，各有適用場景，我們在後面的段落會詳細比較。
燃盡圖的適用範圍不只是單一 Sprint。它可以用在 Sprint 追蹤、Release 追蹤、甚至整個 Epic 的進度監控。我們團隊在導入 Scrum 初期，就是靠一張 Sprint 燃盡圖讓每個人在 Daily Standup 時快速對齊進度，省下大量口頭確認的時間。
燃盡圖的四大類型與適用場景
不是所有燃盡圖都長一樣。根據追蹤範圍的不同，燃盡圖分為四種類型，選錯類型會讓數據失去意義。
Sprint Burndown Chart 是最常見的類型，追蹤單一 Sprint 內的 Story Points 消耗。舉例來說，一個 5 人開發團隊跑 2 週的 Sprint，總共估算 40 個 Story Points，每天在 Daily Standup 後更新剩餘量。這是多數團隊的起點，也是本文後續教學的主要對象。
Release Burndown Chart 跨越多個 Sprint，追蹤某個版本發布的整體進度。假設你的電商平台 Q3 改版需要 6 個 Sprint 才能完成，Release Burndown 會顯示每個 Sprint 結束後的剩餘工作量變化。這對產品經理向利害關係人報告進度特別有用。
Epic Burndown Chart 追蹤大型功能群組的完成狀況。當一個 Epic 橫跨多個 Sprint 且包含數十個 User Story 時，Epic Burndown 能讓你看到這個功能群組的整體收斂趨勢。
Product Burndown Chart 追蹤整個 Product Backlog 的消耗，通常用於長期產品規劃。但要注意，Product Backlog 本身會持續增長，所以這張圖的 Scope 變動會非常頻繁。
| 類型 | 追蹤範圍 | 時間軸 | 適用對象 |
|---|---|---|---|
| Sprint Burndown | 單一 Sprint 的 Story Points | 1-4 週 | Scrum 團隊、Scrum Master |
| Release Burndown | 跨 Sprint 的版本進度 | 1-6 個月 | 產品經理、利害關係人 |
| Epic Burndown | 大型功能群組 | 數週至數月 | 技術主管、架構師 |
| Product Burndown | 整個 Product Backlog | 持續性 | 產品負責人（PO） |
燃盡圖的核心組成元素
要正確建立和判讀燃盡圖，你必須理解它的五個核心組成元素。我們在輔導台灣團隊時發現，很多人畫出來的「燃盡圖」其實缺少關鍵元素，導致圖形無法反映真實狀況。
X 軸（時間軸） 代表 Sprint 的天數或具體日期。如果你的 Sprint 是 2 週（10 個工作天），X 軸就是 Day 1 到 Day 10。記得排除週末和國定假日——台灣的連假特別多，忘記扣除會讓理想線的斜率失真。
Y 軸（工作量） 有三種常見單位，選擇邏輯如下：
- Story Points：最推薦。反映任務的相對複雜度，不受個人能力差異影響。適合已經有估算習慣的敏捷團隊。
- 工時（小時）：適合工作內容高度標準化的團隊，例如製造業的測試流程或客服團隊的工單處理。但工時容易讓人陷入「追蹤個人效率」的陷阱。
- 任務數量：最簡單但最不精確。當每個任務大小差異很大時，一個大任務完成和三個小任務完成在圖上看起來完全不同，容易誤導判斷。
理想燃盡線 是從總工作量直線降至零的基準線。它的斜率 = 總工作量 ÷ Sprint 工作天數。
實際燃盡線 是每日更新的真實剩餘量曲線。注意：這裡追蹤的是「剩餘工作量」，不是「已完成工作量」。這是台灣團隊最常犯的錯誤——用「今天完成了幾個任務」來畫圖，結果圖形方向完全反了。
Scope 變更標記 是當 Sprint 中途新增或移除任務時，在圖上標記的垂直跳動。如果你的 Y 軸突然往上跳，不是團隊退步了，而是有新需求被加進來。這個標記能幫助團隊在 Sprint Retrospective 時回溯 Scope 蔓延的頻率。
如何建立燃盡圖：5 個步驟從零開始
建立燃盡圖不需要昂貴的工具，一張 Excel 試算表就能開始。以下是我們團隊實際使用的 5 步驟流程。
步驟一：估算 Sprint 總工作量
在 Sprint Planning 會議中，團隊需要對每個 User Story 進行估算。最常用的方法是 Planning Poker——每個成員同時出牌，用費波那契數列（1, 2, 3, 5, 8, 13, 21）表示複雜度，再討論差異後取得共識。
如果團隊剛開始導入敏捷，可以先用 T-Shirt Sizing（S/M/L/XL）快速分類，再轉換成數值。我們的經驗是：S=2, M=5, L=8, XL=13 是不錯的起點。
範例：某 SaaS 團隊的 Sprint 共有 8 個 User Story，估算結果如下：
| User Story | 估算 (SP) |
|---|---|
| 用戶登入改版 | 5 |
| 搜尋功能優化 | 8 |
| 通知設定頁面 | 3 |
| API 文件更新 | 2 |
| 報表匯出功能 | 8 |
| 錯誤修復 #142 | 3 |
| 效能監控面板 | 3 |
| 單元測試補充 | 2 |
| 合計 | 34 SP |
這個 34 SP 就是燃盡圖 Y 軸的起始點。用SMART 原則來檢驗：這個數字是否具體、可衡量、團隊認為可達成？
步驟二：設定時間軸與理想線
確定 Sprint 的工作天數後，計算每日應燃盡量：
每日燃盡量 = 總 SP ÷ Sprint 工作天數
以上面的例子：Sprint 為 2 週，扣除週末後有 10 個工作天。每日燃盡量 = 34 ÷ 10 = 3.4 SP。
理想線的數據如下：
| 天數 | 理想剩餘 SP |
|---|---|
| Day 0 | 34.0 |
| Day 1 | 30.6 |
| Day 2 | 27.2 |
| Day 3 | 23.8 |
| Day 4 | 20.4 |
| Day 5 | 17.0 |
| Day 6 | 13.6 |
| Day 7 | 10.2 |
| Day 8 | 6.8 |
| Day 9 | 3.4 |
| Day 10 | 0.0 |
台灣團隊注意：如果 Sprint 期間遇到國定假日（例如清明連假、端午節），記得從工作天數中扣除。忘記扣假日是我們見過最常見的理想線設定錯誤，會讓團隊在假日後看到一個「假性落後」的缺口。
步驟三：每日更新實際剩餘量
每天 Daily Standup 結束後，由 Scrum Master 或指定人員更新實際剩餘 SP。更新的關鍵原則：
- 只計算「剩餘」，不計算「已完成」。如果一個 8 SP 的 Story 完成了一半，剩餘量不是 4 SP——除非團隊有明確的拆分標準，否則在 Story 完成前，它的 SP 仍然全部計入剩餘量。
- 只有符合 Definition of Done 的 Story 才能從剩餘量中移除。「差不多做完了」不算完成。
案例：某台灣金融科技團隊在 Sprint Day 3 發現實際剩餘量是 28 SP（理想值應為 23.8 SP），落後了 4.2 SP。Scrum Master 在當天的 Standup 後立即與 PO 討論，決定將一個 3 SP 的低優先級 Story 移出 Sprint，讓團隊專注在核心功能上。這個決策讓他們在 Sprint 結束時順利交付所有高優先級項目。
步驟四：用 Excel 建立燃盡圖
如果你的團隊還沒有專業的敏捷工具，Excel 或 Google Sheets 是最快的起步方式。欄位設計如下：
| A 欄：日期 | B 欄：理想剩餘 SP | C 欄：實際剩餘 SP | D 欄：備註 |
|---|---|---|---|
| Sprint Day 0 | 34 | 34 | Sprint 開始 |
| Sprint Day 1 | 30.6 | 32 | |
| Sprint Day 2 | 27.2 | 29 | |
| Sprint Day 3 | 23.8 | 28 | Scope 調整：移除 Story #7 |
| … | … | … |
建立折線圖的步驟（Excel / Microsoft 365）：
- 選取 A 欄到 C 欄的所有數據
- 插入 → 圖表 → 折線圖（含資料標記的折線圖）
- 將理想線設為灰色虛線，實際線設為藍色實線
- 加入圖表標題：「Sprint XX Burndown Chart」
- 設定 Y 軸最小值為 0，最大值為總 SP 的 110%
D 欄的「備註」不會出現在圖表上，但對 Sprint Retrospective 時回溯問題非常有用。我們建議在任何 Scope 變更、重大阻礙或人員異動時都留下記錄。
如果你的團隊使用 Microsoft 365，可以搭配 OneDrive 共享試算表，讓所有成員即時查看最新的燃盡圖。
步驟五：用專案管理工具自動生成燃盡圖
手動更新 Excel 適合小團隊或導入初期，但當團隊規模超過 10 人，手動維護的成本會快速上升。這時候你需要一個能自動同步任務狀態的工具。
Jira Software 是目前功能最完整的選擇。開啟路徑：Board → Reports → Burndown Chart。你可以選擇用 Story Points 或 Issue Count 作為估算單位。Jira 會根據每個 Issue 的狀態變更自動更新實際線，不需要手動輸入。
不過 Jira 的學習曲線較陡，介面對非技術人員不太友善。如果你的團隊是跨部門協作（例如行銷 + 開發 + 設計），我們更推薦 monday.com——它的 Sprint 管理功能搭配自動化儀表板，可以在看板上即時顯示燃盡趨勢，而且非技術成員也能在 10 分鐘內上手。免費方案不需要信用卡，適合先試用再決定。
如何判讀燃盡圖：5 種常見走勢與對策
建立燃盡圖只是第一步，真正的價值在於判讀。以下是我們在實務中最常遇到的五種走勢，每一種都對應不同的根因和行動方案。
走勢一：實際線貼近理想線（理想狀態）
當實際線與理想線的偏差在 ±10-15% 以內，代表團隊的估算準確、執行節奏穩定。這是每個 Scrum 團隊追求的目標。
但要注意：連續多個 Sprint 都完美貼合理想線，反而可能代表團隊在「安全範圍」內工作，沒有挑戰自己的 Velocity 上限。某台灣金融科技公司的 Scrum Master 告訴我們，他們連續 3 個 Sprint 達標後，嘗試將 Sprint 承諾量提高 15%，結果發現團隊其實有餘裕，Velocity 從 34 SP 穩定提升到 40 SP。
走勢二：實際線持續高於理想線（進度落後）
這是最常見的警訊。可能原因包括：
- 低估工作量：團隊對新技術或新領域的複雜度判斷不足
- 技術債累積：舊程式碼的維護成本侵蝕了新功能的開發時間
- 人員異動：關鍵成員請假或離職
對策：Scrum Master 應在偏差超過 20% 時主動介入，與 PO 協商移除低優先級的 Story。重點是「減少 Scope」而非「要求加班」——強迫加班只會在下一個 Sprint 產生更多技術債。
我們輔導過一家台灣製造業公司，他們在導入 Scrum 的前三個 Sprint 幾乎每次都落後 30% 以上。根因不是團隊能力不足，而是 PO 習慣在 Sprint 中途塞需求。透過嚴格執行「Sprint 期間不加需求」的規則，到第四個 Sprint 就穩定下來了。
走勢三：實際線低於理想線（進度超前）
進度超前不一定是好事。常見的隱藏問題：
- 估算過於保守：團隊刻意高估 Story Points 以確保「安全交付」
- Definition of Done 不嚴謹：任務被標記為「完成」但品質不達標，後續會產生大量 Bug
- 測試覆蓋不足：開發快但沒有充分測試
對策：如果確認是真正的超前，可以從 Product Backlog 中 Pull in 額外的 Story，或利用多出的時間進行技術優化和程式碼重構。這對長期的團隊生產力提升非常有幫助。
走勢四：實際線呈水平（工作停滯）
當實際線連續 2-3 天完全沒有下降，代表沒有任何 Story 被完成。這通常意味著：
- 阻礙（Impediment）未被解除：等待第三方 API 回覆、等待法務審核、等待設計稿
- 所有 Story 都「進行中」但沒有一個「完成」：團隊同時開太多任務，WIP（Work In Progress）過高
Scrum Master 的介入時機是「水平線出現的第一天」，而不是等到 Sprint 快結束才發現。這也是為什麼每日更新燃盡圖如此重要——它是最早的預警系統。
走勢五：Y 軸數值上升（Scope 蔓延）
當剩餘工作量不降反升，代表 Sprint 中途被加入了新需求。這是台灣團隊最常遇到的痛點，尤其是在老闆或客戶「臨時想到一個小功能」的時候。
如何在圖上標記 Scope 變更：在實際線出現向上跳動的那一天，用垂直虛線標記，並在旁邊註明新增的 SP 數量和原因。例如：「+5 SP：客戶要求新增匯出 PDF 功能」。
向 PO 溝通的話術：「這個需求我們可以加入，但根據燃盡圖，目前的進度已經落後理想線 X%。如果要加入這 5 SP 的新需求，我們需要移出等量的低優先級 Story，否則 Sprint Goal 會無法達成。你希望移除哪些項目？」
這段話的關鍵是「讓 PO 做選擇」，而不是「團隊說不行」。燃盡圖在這裡扮演的角色是客觀的數據證據，讓溝通從「感覺」變成「事實」。
以下是判讀速查表，建議列印貼在團隊的白板旁邊：
| 走勢 | 可能原因 | 建議對策 |
|---|---|---|
| 貼近理想線 | 估算準確、節奏穩定 | 維持現狀，考慮提升挑戰度 |
| 持續高於理想線 | 低估工作量、技術債、人員異動 | 與 PO 協商減少 Scope |
| 低於理想線 | 估算保守、DoD 不嚴謹 | Pull in 額外 Story 或技術優化 |
| 水平線 | 阻礙未解除、WIP 過高 | Scrum Master 立即介入排除阻礙 |
| Y 軸上升 | Sprint 中途新增需求 | 標記 Scope 變更，與 PO 協商交換 |
燃盡圖 vs. 燃起圖（Burnup Chart）怎麼選？
燃起圖（Burnup Chart）和燃盡圖追蹤的是同一件事，但方向相反。燃起圖的 Y 軸代表「已完成工作量」，曲線從零向上累積，直到達到總工作量。
兩者最關鍵的差異在於 Scope 變更的可見性。
在燃盡圖上，如果 Sprint 中途新增了 10 SP 的需求，你會看到實際線突然向上跳——但你無法一眼分辨「這是因為新增需求，還是因為團隊退步了」。
在燃起圖上，已完成量的曲線持續向上，而總工作量會以另一條線顯示。當 Scope 增加時，「總工作量線」會向上移動，但「已完成量線」不受影響。這讓你能清楚看到：「團隊一直在穩定交付，是 Scope 在膨脹。」
選擇框架：
- 如果你的 Sprint Scope 穩定（中途幾乎不加需求）→ 用燃盡圖，更直覺
- 如果 Scope 頻繁變動，或需要向非技術的利害關係人報告進度 → 用燃起圖，更容易解釋
- 如果你是專案管理新手，先從燃盡圖開始，熟悉後再考慮燃起圖
補充：Velocity Chart（速度圖）的互補角色
燃盡圖告訴你「這個 Sprint 的進度如何」，但無法告訴你「團隊的長期產能趨勢」。這時候需要搭配 Velocity Chart——它記錄每個 Sprint 的實際完成 SP，讓你看到團隊的平均速度是在提升、穩定還是下降。
實務上，我們會用 Velocity Chart 來設定下一個 Sprint 的承諾量（取最近 3-5 個 Sprint 的平均 Velocity），再用燃盡圖來追蹤執行過程。兩者搭配使用，才是完整的敏捷進度管理。
燃盡圖工具推薦與比較
選擇工具的核心考量是團隊規模和技術成熟度。以下是我們實際測試過的方案，依適用場景分類。
專業敏捷工具
Jira Software 是功能最完整的選擇，內建 Sprint Burndown 和 Release Burndown，支援 Story Points 和 Issue Count 兩種估算模式。適合 10 人以上的純技術團隊。費用約 NT$260/人/月（Standard 方案）。缺點是設定複雜，非技術成員上手困難。
Azure DevOps 適合已經深度使用微軟生態系的企業。如果你的團隊用 Visual Studio + Teams + Microsoft 365，Azure DevOps 的整合體驗會很流暢。燃盡圖功能在 Analytics Views 中，需要額外設定。
跨部門協作工具
monday.com 是我們團隊的首選。它的 Sprint 管理功能讓你在看板上直接追蹤任務狀態，搭配儀表板可以自動生成進度趨勢圖。最大的優勢是非技術成員也能快速上手——我們的行銷同事第一天就學會更新任務狀態，不需要任何培訓。免費方案支援最多 2 位使用者，不需要信用卡。
（推薦試試 monday.com 的免費方案，我們團隊實際使用後跨部門協作效率提升明顯。）
ClickUp 是技術導向團隊的好選擇。它的 Sprint 功能內建燃盡圖，支援 Story Points 估算，而且免費方案的功能比多數工具的付費方案還豐富。適合 5-15 人的開發團隊。
免費 / 自建方案
Excel / Google Sheets 是成本最低的方案，適合 10 人以下的小團隊或剛開始導入 Scrum 的團隊。本文步驟四已經提供完整的欄位設計，你可以直接照著做。缺點是需要手動更新，容易遺忘。
以下是工具比較總覽：
| 工具 | 燃盡圖功能 | 月費（每人） | 適合規模 | 免費方案 |
|---|---|---|---|---|
| monday.com | 儀表板趨勢圖 + 自動化 | NT$270 起 | 5-50 人跨部門 | ✅ 2 人 |
| ClickUp | 內建 Sprint Burndown | NT$210 起 | 5-15 人技術團隊 | ✅ 功能豐富 |
| Jira Software | Sprint + Release Burndown | NT$260 起 | 10 人以上技術團隊 | ✅ 10 人 |
| Azure DevOps | Analytics Views | NT$180 起 | 微軟生態系企業 | ✅ 5 人 |
| Excel / Sheets | 手動折線圖 | 免費 | 10 人以下 | ✅ |
你是哪種團隊？
- 5 人以下、剛開始接觸 Scrum → 先用 Excel，熟悉流程後再升級
- 5-15 人跨部門協作 → monday.com（我們的首選）
- 5-15 人純技術團隊跑 Scrum → ClickUp
- 15 人以上的大型技術專案 → Jira Software 或 monday.com 企業方案
燃盡圖的優缺點與常見誤用
燃盡圖不是萬能的。了解它的限制，才能正確使用它。
優點：
- 即時可視化：一張圖就能讓所有人在 30 秒內理解 Sprint 進度
- 早期預警：偏差在 Day 2-3 就能被發現，而不是等到 Sprint 結束
- 促進 Daily Standup 聚焦：團隊討論的焦點從「我昨天做了什麼」轉向「我們離目標還有多遠」
缺點：
- 無法反映工作品質：燃盡圖只追蹤數量，不追蹤品質。一個充滿 Bug 的 Story 和一個完美的 Story 在圖上看起來一樣
- 容易被「刷數字」操弄：有些團隊為了讓圖好看，會把一個 8 SP 的 Story 拆成四個 2 SP 的子任務，然後快速「完成」前三個簡單的部分
- 不適合 Kanban 或非迭代式專案：燃盡圖需要固定的時間框架（Sprint），Kanban 團隊應改用 Cumulative Flow Diagram（CFD）
台灣團隊常見的三大誤用：
誤用一：主管用燃盡圖考核個人績效。 燃盡圖是團隊層級的工具，不是個人績效指標。當主管開始用它來比較「誰完成的 SP 比較多」，團隊會開始搶簡單的任務、避開困難的任務，最終破壞心理安全感和協作文化。如果你是主管，請把燃盡圖當作「團隊健康度指標」，而不是「個人 KPI」。
誤用二：只在 Sprint Review 才更新。 如果你一週才更新一次，燃盡圖就失去了「即時預警」的核心價值。等到 Sprint Review 才發現落後 40%，已經來不及了。正確做法是每天 Daily Standup 後立即更新。
誤用三：混用工時與 Story Points。 有些團隊在同一張圖上，部分 Story 用工時估算、部分用 SP 估算，導致 Y 軸的數據完全沒有可比性。選定一種單位後，整個 Sprint 必須一致。
結論
燃盡圖是 Scrum 團隊最基礎也最實用的進度追蹤工具。掌握它的建立方法和判讀技巧，能讓你的 Sprint 管理從「憑感覺」升級到「看數據」。
回顧本文重點：
- 燃盡圖的核心是「剩餘工作量 vs. 剩餘時間」的折線圖，理想線與實際線的差距就是你的進度健康度
- 四大類型（Sprint / Release / Epic / Product）對應不同的追蹤範圍，多數團隊從 Sprint Burndown 開始即可
- 建立只需 5 步驟：估算總量 → 設定理想線 → 每日更新 → 用 Excel 或工具繪製 → 在 Daily Standup 中判讀
- 5 種走勢各有對策：落後時減少 Scope、停滯時排除阻礙、Scope 蔓延時用數據與 PO 溝通
- 避免三大誤用：不拿來考核個人、每天更新、統一估算單位
想把這篇文章的方法論付諸實踐？第一步：在 monday.com 建立一個 Sprint 看板，把你的 User Story 填入，設定好時間軸和狀態欄位，搭配儀表板就能自動追蹤進度趨勢。10 分鐘就能建好你的第一個 Sprint 追蹤框架，免費方案不需要信用卡。
燃盡圖常見問題 FAQ
燃盡圖一定要用 Story Points 嗎？可以用工時嗎？
兩者皆可，但適用場景不同。Story Points 反映的是任務的「相對複雜度」，不受個人能力差異影響，適合大多數敏捷團隊。工時適合工作內容高度標準化的團隊，例如 QA 測試流程或客服工單處理。我們的建議是：如果團隊剛開始導入 Scrum，先用任務數量（最簡單），穩定後再轉換成 Story Points。
燃盡圖適合 Kanban 團隊嗎？
不適合。燃盡圖需要固定的時間框架（Sprint）和預先定義的工作量，而 Kanban 是持續流動的模式，沒有固定的迭代週期。Kanban 團隊建議改用 Cumulative Flow Diagram（CFD），它能追蹤各狀態欄位中的任務數量變化，更符合 Kanban 的運作邏輯。
Sprint 中途新增需求，燃盡圖要怎麼處理？
在圖上標記 Scope 變更點：用垂直虛線標示新增需求的日期，Y 軸數值向上調整（加上新增的 SP），並在備註中記錄原因和新增量。例如：「Day 5 新增 +5 SP：客戶要求匯出 PDF 功能」。這個標記在 Sprint Retrospective 時非常有用，能幫助團隊量化 Scope 蔓延的頻率和影響。
燃盡圖顯示進度落後，Scrum Master 應該怎麼做？
第一步是找出根因：是估算不準、有阻礙未解除、還是 Scope 被偷偷加大？確認根因後，與 PO 協商移除低優先級的 Story，確保 Sprint Goal 仍然可達成。關鍵原則是「減少 Scope」而非「要求加班」。如果落後是因為阻礙（例如等待外部 API），Scrum Master 的職責是立即介入排除，而不是等團隊自己解決。
Excel 燃盡圖和專業工具的燃盡圖有什麼差別？
Excel 需要每天手動輸入剩餘 SP，適合 10 人以下的小團隊或導入初期。專業工具（如 Jira、monday.com、ClickUp）會自動同步任務狀態，當 Story 被標記為「完成」時，燃盡圖即時更新。如果你的團隊超過 10 人，或者經常忘記更新 Excel，建議升級到自動化工具，省下的時間遠超過工具的費用。
