[內科園區某棟白色建築公司的電梯一隅]
Sprint Review 前一天，產品負責人 Wilson 在中午等電梯時，巧遇架構師兼全端工程師 Leo

Wilson：「Hi Hi Leo，那個單一登入的功能你完成了嗎？」
Leo：「當然，明天就要 Demo 了，我早就已經完成嘍！別擔心，妥妥的~」

嗶嗶~~ 此處有雷，大家得要小心避開：
在這個情境中，我們真的知道 Leo 所謂的「都完成了」是指什麼意思嗎？甚至，苦主 Leo 知道 Wilson 所謂的「完成」，又是什麼意思呢？

Wilson 與 Leo 可能同樣都使用「完成」這個詞，但腦海中想的卻完全不是同一件事。Leo 因為背景是開發工程師，他所謂的完成，指的可能只是已經寫好程式碼，提交 Code Review 了（過程中可能還有會被 Reject 而需要重新改 Code 再提交重審的風險）；而 Wilson 因為是產品端的角色，所以他所問語句中的「完成」，所指的其實是，是不是已經通過了 QT 的測試，隨時可推到 Production 環境進行發佈的狀態。

定義什麼是完成

完成的定義英文是 Definition of Done，簡稱 DoD，是一種團隊之間對於完成的共識。由於人類語言在本質上是相當抽象的，愈高階的詞彙，愈不那麼精確，Scrum 團隊最好能夠在專案剛開始、Team 剛建立起來時，花些時間討論各方的期待、組織的慣例，共同決定出彼此認定的「完成」的定義，必要時也可將 DoD 共識寫進團隊的 Wiki 文件中，當有新成員加入時馬上就能夠進入狀況。

就 Scrum 的訴求－每次 Sprint 結束後，都能產出一個可交付的產品來看，較佳的完成定義是「潛在可交付產品增量」（Icrement），這對產品負責人來說也是比較有價值的結果。

常見完成的定義

不過，不同團隊在不同的事業發展階段，其 DoD 可能會有不同的定義，因此，完成的定義會「因時制宜」，甚至有可能會「因地制宜」，並不是永遠固定不變的。

那麼，常見的『完成的定義』項目有哪些呢？羅列如下：

1. 寫完程式碼
2. 做完單元測試沒問題
3. 提交程式碼審查
4. 做完整合測試沒問題
5. 通過自動化測試／手動測試
6. 撰寫完相關開發文件、API 文件、Wiki 等
7. 完成 Stage 環境部署
8. 通過 Google Play ／ App Store 審核，已成為準上架狀態 (APP)
9. 完成 Production 環境部署

完成定義與驗收標準的差別

這裡需要特別注意的是，這篇所在討論的 DoD（完成的定義），它與驗收標準（Acceptance Criteria）是二件不一樣的事，後者更強調的是屬於負責人或客戶的觀點，定義了什麼是「可接受」的產品，它必須滿足一些特定的條件（比如說效能、法律合規或壓力測試等等），在甲乙方的情境中，驗收條件更是會被明確的記下，寫成一個文件紀錄，而前述所提到的像是單元測試、撰寫 API 文件、測試 API 向下相容性等等，一般而言是不會被包含在驗收標準的範圍中的。簡單來說，完成的定義歸開發團隊所有，關注點是在考量到若產品要能夠交付，必須要做完哪些在冰山之下得完成的工作。

若不重視完成的定義，會造成許多風險，比如說會累積出許多看不見的債雪球，隨著時間推移，這些雪球愈滾愈大（aka. 債愈來愈多），這些雪球債會存在於原本的計劃之外，每次產品交付之前都還是得需要再進行處理。