Definition of Done（DoD，完成定義）是 Scrum 團隊對「一項工作真正完成」所達成的共同標準。這篇文章將帶你從零理解 DoD 的定義與價值，提供軟體與非軟體團隊的實務範例，並用 5 個步驟建立你自己的完成定義清單。
什麼是 Definition of Done（DoD）？
Definition of Done（簡稱 DoD，中文常譯為「完成定義」）是整個 Scrum Team 對「一個 Product Backlog Item 在什麼條件下才算真正完成」所建立的共識標準。它不是某個人的主觀判斷，而是團隊所有成員——開發者、Product Owner、Scrum Master——共同承諾遵守的品質門檻。
一句話定義： DoD 是一份明確的清單，列出每個 Increment 必須滿足的條件，只有全部達標，工作才算「Done」。
很多團隊在初期會把「完成」等同於「程式碼寫完了」或「任務狀態改成 Done」。但在 Scrum 框架中，DoD 的意義遠不止於此。它涵蓋了程式碼品質、測試、文件、部署等多個面向，確保每個 Sprint 產出的 Increment 都是可交付的。
舉個例子：一位工程師把功能開發完畢，在看板上把卡片拖到「完成」欄位。但如果團隊的 DoD 要求「必須通過 Code Review、單元測試覆蓋率達 80%、已部署至 Staging 環境」，那這張卡片其實還沒有真正 Done。
這個區別至關重要。沒有 DoD 的團隊，每個人對「完成」的定義不同，最終在 Sprint Review 時才發現功能根本無法展示——這是我們團隊在早期踩過的坑。
DoD 為什麼重要？三個核心價值
如果你正在考慮「我們團隊真的需要 DoD 嗎？」，以下三個價值會幫你做出判斷。
透明度：消除「我以為你做完了」的溝通黑洞
沒有 DoD 的團隊，最常出現的場景是：PO 問「這個功能完成了嗎？」工程師說「完成了」，但 PO 期待的是「使用者可以在正式環境操作」，工程師的意思卻是「程式碼已經 push 上去了」。
DoD 把這層隱性認知差異攤開來。當所有人都看著同一份清單，「完成」就不再是模糊的概念，而是可驗證的事實。這種透明度對跨部門協作尤其關鍵——如果你的團隊也常遇到溝通落差，可以參考主管領導力的建立方式來強化團隊共識。
品質保障：防止技術債悄悄累積
我們曾經輔導過一個台灣的 SaaS 團隊，他們在沒有 DoD 的情況下跑了 8 個 Sprint。每次 Sprint Review 前夕，QA 都在趕測試，工程師則在修前幾個 Sprint 遺留的 Bug。原因很簡單：沒有人規定「測試通過」是完成的必要條件，所以測試步驟經常被跳過。
後來他們建立了一份 7 條的 DoD，其中包含「單元測試通過」和「QA 回歸測試完成」。三個 Sprint 後，Sprint Review 前的緊急修補次數從平均 12 次降到 2 次。
可預測性：讓 Velocity 估算更準確
當 DoD 標準穩定，每個 Story 的「完成」代表相同程度的工作量。這讓團隊的 Velocity 數據更有參考價值，Sprint Planning 時的承諾也更可靠。反之，如果有些 Sprint 的「完成」包含測試，有些不包含，Velocity 數字就會忽高忽低，失去預測意義。
DoD 實務範例：不同情境的完成定義長什麼樣？
理解了 DoD 的概念後，最常見的問題是：「那實際上要寫什麼？」以下提供三種情境的範例，你可以直接參考並調整。
軟體開發團隊的 DoD 範例
這是最經典的 DoD 應用場景。以下是一份中型軟體團隊（8-15 人）常見的 DoD 清單：
- ✅ 程式碼已通過至少一位同事的 Code Review
- ✅ 單元測試覆蓋率達 80% 以上
- ✅ 所有自動化測試通過（CI Pipeline 綠燈）
- ✅ 功能已部署至 Staging 環境並可操作
- ✅ 相關文件已更新（API doc / README / Changelog）
- ✅ 無已知 Critical 或 Major Bug
- ✅ PO 已在 Staging 環境確認功能符合預期
這份清單的每一條都是可驗證的——你可以在 30 秒內判斷「有」或「沒有」，不存在模糊空間。
非軟體團隊的 DoD 範例
DoD 不是工程團隊的專利。任何需要多人協作、且對「完成」有不同理解的工作，都能受益於明確的完成定義。
行銷活動 Story 的 DoD：
- ✅ 文案已經過主管審核並核准
- ✅ 視覺素材已上傳至廣告平台
- ✅ UTM 追蹤碼已設定並測試
- ✅ Landing Page 預覽連結已確認可正常開啟
- ✅ A/B 測試變體已建立
營運流程改善 Story 的 DoD：
- ✅ SOP 文件已更新至最新版本
- ✅ 相關人員已完成教育訓練（含簽到紀錄）
- ✅ 新流程已在至少一個案例中試行
- ✅ 試行結果已記錄並回報
如果你的團隊正在進行數位轉型，為非軟體流程建立 DoD 是確保轉型品質的有效方法。
DoD 的層級結構
DoD 不只存在於單一 Story 層級。成熟的團隊會建立三層嵌套結構：
Story 層級 DoD： 每個 User Story 完成時必須滿足的條件（如上述範例）。
Sprint 層級 DoD： 整個 Sprint 結束時，所有完成的 Story 必須額外滿足的條件。例如：「所有功能已整合測試通過」、「Release Notes 已撰寫」。
Release 層級 DoD： 產品發布前必須滿足的條件。例如：「效能測試通過（頁面載入 < 3 秒）」、「安全性掃描無高風險漏洞」、「使用者文件已更新」。
三者的關係是：Release DoD 包含 Sprint DoD，Sprint DoD 包含 Story DoD。每一層都是在前一層的基礎上增加更嚴格的條件。
DoD、Acceptance Criteria、Definition of Ready 差異比較
這三個概念是台灣 Scrum 團隊最常混淆的。我們用一張表格和一個比喻，幫你一次釐清。
| 比較項目 | Definition of Done（DoD） | Acceptance Criteria（AC，驗收標準） | Definition of Ready（DoR，就緒定義） |
|---|---|---|---|
| 定義 | 所有 Story 都必須滿足的通用完成標準 | 針對單一 Story 的特定驗收條件 | Story 進入 Sprint 前必須達到的準備標準 |
| 適用範圍 | 全團隊、所有 Story | 單一 Story | 全團隊、所有 Story |
| 由誰制定 | 整個 Scrum Team | PO 主導，開發者確認可行性 | 整個 Scrum Team |
| 適用時機 | Story 完成時檢查（輸出端） | Story 完成時檢查（輸出端） | Sprint Planning 時檢查（輸入端） |
| 範例 | 「所有功能必須有單元測試」 | 「使用者可用 Google 帳號登入」 | 「Story 必須有明確的 AC 才能進 Sprint」 |
用一個比喻來理解：
把 Sprint 想像成一所學校。DoR 是「入學資格」——你必須準備好才能進來（Story 必須有明確的 AC、估點已完成）。AC 是「每科的考試題目」——每個 Story 有自己要通過的特定測驗。DoD 是「畢業門檻」——不管你讀哪個科系，畢業前都必須滿足的通用標準（如英文檢定、體育學分）。
一個 Story 要算真正完成，必須同時滿足它自己的 AC 和團隊的 DoD。兩者缺一不可。
如果你想更深入了解如何用結構化的方式管理這些標準，建議參考流程圖的製作方法，將 DoD 檢查流程視覺化。
如何建立你的 DoD：5 個步驟
以下是我們團隊實際使用、也推薦給客戶的 DoD 建立流程。每個步驟都附上常見錯誤，幫你避開地雷。
Step 1：召集對的人
DoD 必須由整個 Scrum Team 共同制定。這代表開發者、QA、Product Owner、Scrum Master 都要在場。
台灣團隊最常犯的錯誤： PM 或 Tech Lead 自己寫好一份 DoD，然後在會議上「宣布」。結果開發者覺得「這不是我同意的標準」，執行率極低。DoD 的力量來自共識，不是命令。
實務上，我們建議用一場 60-90 分鐘的工作坊來完成。如果團隊成員超過 10 人，可以先分小組討論再彙整。
Step 2：盤點品質標準
最有效的起點是回顧過去的痛點。請團隊回答這個問題：
「我們曾經因為什麼原因返工？」
把答案列出來，你會發現大部分返工都可以追溯到某個被跳過的步驟。例如：
- 「上線後發現 Bug」→ 需要加入「測試通過」
- 「PO 說這不是他要的」→ 需要加入「PO 已在 Staging 確認」
- 「文件沒更新，新人看不懂」→ 需要加入「文件已更新」
此外，也要考慮組織層級的要求。例如金融業團隊可能需要加入「資安稽核項目已通過」，醫療產業可能需要「符合 HIPAA 合規要求」。
善用艾森豪矩陣的思維，優先把「重要且緊急」的品質標準納入 DoD，避免一開始就列出過多條目。
Step 3：建立完成清單（Checklist）
把 Step 2 盤點出的標準，整理成一份 5-10 條的清單。
關鍵原則：每條必須是可驗證的（Verifiable）。
- ❌「程式碼品質良好」（誰來判斷「良好」？）
- ✅「程式碼通過 SonarQube 掃描，無 Critical Issue」
- ❌「已充分測試」（什麼叫「充分」？）
- ✅「單元測試覆蓋率達 80% 以上，且 CI Pipeline 全部通過」
條目數量的建議：5 條是最低門檻（太少等於沒有），10 條是上限（太多會讓團隊疲於應付，反而降低執行意願）。剛開始建立 DoD 的團隊，建議從 5-7 條開始。
Step 4：對應到 User Story 與 Sprint 流程
DoD 建好後，必須融入日常工作流程，否則就只是一份被遺忘的文件。
Sprint Planning 時： 確認當前的 DoD 是否仍適用於這個 Sprint 的工作內容。如果這個 Sprint 有特殊需求（例如第一次做國際化），可能需要臨時增加條目。
Daily Scrum 時： 當有人說「這個 Story 快完成了」，可以快速對照 DoD 確認還差哪些條目。
Sprint Review 時： 只展示符合 DoD 的 Increment。如果某個 Story 的 DoD 沒有全部達標，它就不算完成，不應該在 Review 中展示。
這個步驟的關鍵是讓 DoD 成為團隊的日常語言，而不是季度回顧時才翻出來看的文件。如果你在寫企劃書或專案章程時，也可以把 DoD 的概念納入品質管理計畫中。
Step 5：定期回顧與更新
DoD 不是一成不變的。隨著團隊成熟度提升，DoD 標準應該逐步提高。
最佳的回顧時機是 Sprint Retrospective。 在 Retro 中加入一個固定議程：「我們的 DoD 需要調整嗎？」
我們輔導過的一個台灣電商團隊，在第 6 個 Sprint 後將「效能測試（頁面載入時間 < 3 秒）」加入 DoD。原因是前 5 個 Sprint 上線後，客服頻繁收到「網頁跑很慢」的投訴。加入這條之後，效能問題在上線前就被攔截，客訴量下降了 60%。
DoD 演進的典型路徑：
- 初期：手動測試通過、Code Review 完成
- 中期：自動化測試覆蓋、CI/CD Pipeline 整合
- 成熟期：效能測試、安全掃描、可觀測性（Observability）指標設定
DoD 常見陷阱與最佳實務
建立 DoD 不難，難的是持續執行。以下是我們觀察到最常見的陷阱，以及對應的解法。
❌ 陷阱 1：條目太模糊 「程式碼品質良好」、「已充分測試」這類描述，每個人的解讀都不同。 ✅ 解法： 每條都用可量化或可驗證的方式描述。「通過 SonarQube 掃描，無 Critical Issue」比「品質良好」有效一百倍。
❌ 陷阱 2：DoD 只存在文件裡，沒人看 寫好一份漂亮的 DoD 文件，放在 Confluence 某個角落，然後再也沒人打開。 ✅ 解法： 讓 DoD 可見（Visible）。貼在實體看板旁邊、設為協作工具的首頁、或整合進每張任務卡片的 Checklist。我們團隊的做法是在 monday.com 的每個任務模板中內建 DoD Checklist，新建任務時自動帶入，不需要額外記憶。
❌ 陷阱 3：不同子團隊有不同 DoD 前端團隊的 DoD 不包含「API 文件更新」，後端團隊的 DoD 不包含「UI 測試通過」。結果整合時才發現兩邊的「完成」拼不起來。 ✅ 解法： 至少要有一份全團隊共用的基礎 DoD。子團隊可以在此基礎上增加條目，但不能減少。
❌ 陷阱 4：DoD 長期不更新 團隊能力已經進步了，但 DoD 還停留在半年前的標準。 ✅ 解法： 每個 Sprint Retrospective 都花 5 分鐘檢視 DoD。不需要每次都改，但要確保它反映團隊當前的能力和需求。
❌ 陷阱 5：為了趕進度降低 DoD 標準 Sprint 快結束了，有個 Story 差一條 DoD 沒達標，PM 說「這次先算了，下個 Sprint 補」。 ✅ 解法： 當 DoD 無法在 Sprint 內達成時，應該縮小 Story 範圍，而非降低 DoD 標準。DoD 是品質底線，一旦開了先例，團隊會習慣性地妥協。
如果你的團隊正在面對這些挑戰，建議在 Retrospective 中使用結構化的回顧方法。可以參考心流狀態的概念，幫助團隊在高品質標準下仍能保持專注與效率。
用數位工具管理 DoD
DoD 的價值在於執行，而執行的關鍵是讓它融入團隊每天使用的工具。以下是幾種常見工具的整合方式。
monday.com：自動化 DoD Checklist
我們團隊實際使用 monday.com 管理 Sprint 任務。具體做法是：在任務模板中預設一組 DoD Checklist 欄位，每次建立新任務時自動帶入。更進一步，我們設定了一條自動化規則：「當 Checklist 全部勾選完成時，自動將任務狀態改為 Done 並通知 PO」。這個設定確保沒有人可以在 DoD 未達標的情況下手動把任務標記為完成。
對於 5-15 人的跨部門團隊，monday.com 的看板視圖讓所有人一眼就能看到每個任務的 DoD 達成狀況，不需要逐一點開確認。免費方案不需要信用卡，適合先試用看看是否符合團隊需求。
ClickUp：Sprint 與 DoD 深度整合
如果你的團隊是技術導向、已經在跑 Scrum，ClickUp 的 Sprint 功能與 DoD 整合得相當緊密。你可以在 Space 層級設定全域 DoD Template，每個 Task 自動繼承。ClickUp 的 Custom Fields 功能也允許你為不同類型的 Story（前端、後端、設計）設定不同的額外 DoD 條目，同時保留共用的基礎標準。
Notion：適合中小型團隊的輕量方案
對於 5 人以下的新創團隊，Notion 的 Database Template 功能可以快速建立 DoD 管理系統。建立一個「DoD 清單」Database，然後在每個任務的 Template 中用 Relation 連結到這份清單。每次建立新任務時，DoD 條目自動出現在任務頁面中。
Notion 的另一個優勢是可以同時作為團隊 Wiki，把 DoD 的說明文件、歷史版本、修改紀錄都集中管理。如果你的團隊也在用 Notion 做筆記管理，這個整合會特別順暢。
工具比較表
| 工具 | 適合團隊規模 | DoD 整合方式 | 起始費用 |
|---|---|---|---|
| monday.com | 5-50 人跨部門團隊 | 任務模板 Checklist + 自動化規則 | 免費（3 人以下）；NT$270/人/月起 |
| ClickUp | 5-30 人技術團隊 | Space 層級 DoD Template + Custom Fields | 免費；NT$210/人/月起 |
| Notion | 1-10 人新創團隊 | Database Template + Relation | 免費；NT$240/人/月起 |
（推薦試試 monday.com 的免費方案，我們團隊實際使用後發現 DoD Checklist 搭配自動化規則是最省心的管理方式）
結論
Definition of Done 看似只是一份簡單的清單，但它對團隊的品質文化有深遠影響。回顧本文的重點：
- DoD 是團隊共識，不是個人標準。 它必須由整個 Scrum Team 共同制定，才有執行力。
- DoD 的核心價值是透明度、品質保障和可預測性。 沒有 DoD 的團隊，返工率和溝通成本會持續攀升。
- DoD 不限於軟體團隊。 行銷、營運、任何多人協作的工作都能受益。
- 建立 DoD 的關鍵是「可驗證」。 每條標準都要能在 30 秒內判斷是否達成，避免模糊描述。
- DoD 應隨團隊成熟度演進。 每個 Sprint Retrospective 都是檢視和提升 DoD 的好時機。
如果你想更系統化地管理專案品質，也可以參考商業模式的框架思維，從更高的層次思考團隊的價值交付流程。
你的下一步： 在這週的 Sprint Retrospective 中，花 30 分鐘和團隊一起完成 Step 1 到 Step 3。如果你需要一個工具來承載這份 DoD，在 monday.com 用任務模板建立 Checklist 欄位，10 分鐘就能讓 DoD 融入每天的工作流程。
Definition of Done 常見問題
DoD 由誰負責制定？
整個 Scrum Team 共同制定。Scrum Master 負責引導討論流程，Product Owner 確保 DoD 符合業務與品質需求，開發者確保每條標準在技術上可行且可執行。任何單方面制定的 DoD 都會缺乏執行力。
DoD 和驗收標準（Acceptance Criteria）有什麼不同？
DoD 是適用於所有 Story 的通用完成門檻（例如「必須有單元測試」），AC 是針對單一 Story 的特定條件（例如「使用者可用 Google 登入」）。兩者都滿足才算真正完成。詳細比較請參考本文的 DoD、AC、DoR 差異比較段落。
沒有在做 Scrum，也需要 DoD 嗎？
需要。任何多人協作的工作都能受益於明確的完成定義。無論你用 Kanban、Scrumban 或一般的專案管理方法，只要團隊對「完成」的認知不一致，DoD 就能幫你解決這個問題。
DoD 需要多詳細？
建議 5-10 條。每條必須能在 30 秒內判斷是否達成。太少（< 5 條）形同虛設，太多（> 10 條）會讓團隊疲於應付。剛開始建立的團隊從 5-7 條起步，隨成熟度逐步增加。
DoD 多久應該更新一次？
建議每個 Sprint Retrospective 都花 5 分鐘檢視。不需要每次都修改，但要確保 DoD 反映團隊當前的能力。當團隊頻繁遇到某類問題（如效能、安全性），就是該把新條目加入 DoD 的時機。如果你對如何有效管理時間和優先順序有興趣，也可以參考問卷設計的方法來收集團隊對 DoD 的回饋。
