Sprint 是 Scrum 框架的骨架（skeleton），所有的 Scrum 活動與產出物都圍繞著它運作。本章深入探討 Sprint 的核心特性：時間盒（Timeboxed）、短時程（Short Duration）、一致長度（Consistent Duration）、禁止目標變更（No Goal-Altering Changes），以及完成的定義（Definition of Done）。

時間盒（Timeboxed）#

Sprint 以時間盒為基礎——擁有固定的開始與結束日期。在這段時間內，團隊以可持續的步調完成對齊 Sprint 目標的工作。

時間盒帶來以下好處：

短時程（Short Duration）#

Sprint 的長度在一週到一個日曆月之間。短時程帶來多重好處：

容易規劃#

規劃幾週的工作遠比規劃六個月容易。短時程規劃所需的努力更少、準確度也更高。

快速回饋#

每個 Sprint 結束時都會產出可運作的軟體，團隊有機會檢視並調整「建了什麼」和「怎麼建的」。快速回饋能在不利的方向累積更多錯誤決策之前及時修正，也能更快發掘突發的商機。

提升投資報酬率#

短 Sprint 讓我們能更早、更頻繁地交付，從而更快產生收入，改善整體投資報酬率（ROI）。

限制錯誤範圍（Bounded Error）#

兩週 Sprint 最壞的情況就是損失兩週。短時程透過頻繁的協調與回饋來限制錯誤的範圍——即使犯錯，也只是小規模的錯誤。

恢復熱情#

人性使然，等待的時間越長，興奮與興趣就越低。長期的「煮沸海洋」專案（boil-the-ocean projects）讓人失去動力。短 Sprint 透過頻繁交付可運作的成果，持續注入成就感與動力。

頻繁的檢查點#

瀑布式開發的里程碑雖然從治理角度有用，但無法可靠反映客戶價值的交付狀態。Scrum 在每個短 Sprint 結束時都有一個有意義的檢查點（Sprint Review），讓所有人基於可展示的、可運作的功能來做決策。更多的檢查點意味著更強的環境適應能力。

一致的 Sprint 長度（Consistent Duration）#

團隊應選定一致的 Sprint 長度，除非有充分理由才變更。合理的變更理由包括：

• 考慮從四週縮短到兩週以獲取更頻繁的回饋，想先試行幾個 Sprint
• 年度假期或會計年度結束，使三週 Sprint 比平常的兩週更為實際
• 產品即將在一週後發佈，跑兩週 Sprint 會造成浪費

以下不是變更 Sprint 長度的合理理由：

• 團隊無法在目前的 Sprint 長度內完成所有工作
• Sprint 最後一天才發現做不完而要求延長

這些是功能障礙的症狀與改善的機會，不是延長 Sprint 的理由。

節奏的好處（Cadence Benefits）#

一致的 Sprint 長度提供節奏（cadence）——如同穩定的心跳：

• 團隊與組織能建立韻律性的熟悉感，知道什麼時候該做什麼
• 讓例行活動成為習慣，釋放心智容量給增值工作
• 平均化工作強度，不像瀑布式在後期急遽升高
• 大幅降低協調開銷——可一次排定多個 Sprint 的規劃、Review 和 Retrospective 的行事曆
• 多團隊共同開發時，一致的節奏有助於跨團隊同步

簡化規劃#

一致長度讓團隊穩定掌握每個 Sprint 能完成的工作量（即速率 velocity）。若 Sprint 長度不一，「平均每 Sprint 完成 20 點」就失去意義。一致的 Sprint 長度也讓計算固定日期上線前有幾個 Sprint 變成簡單的日曆數學。

不可變更 Sprint 目標（No Goal-Altering Changes）#

一旦 Sprint 目標確立並開始執行，不允許任何可能實質影響 Sprint 目標的變更。

什麼是 Sprint 目標？#

每個 Sprint 應有一個描述商業目的與價值的 Sprint 目標，通常有明確的單一焦點，例如：

• 支援初始報表產生
• 載入並整理北美地圖資料
• 展示透過整合軟體、韌體與硬體堆疊發送簡訊的能力

雙向承諾（Mutual Commitment）#

Sprint 目標是團隊與 Product Owner 之間的雙向承諾：

• 團隊承諾在 Sprint 結束前達成目標
• Product Owner 承諾在 Sprint 期間不更改目標

這種承諾平衡了業務適應變化的需求與團隊專注創造價值的需求。

變更 vs. 釐清（Change vs. Clarification）#

• 變更（Change）：任何可能產生經濟上有意義的浪費、破壞工作流程、或大幅擴張範圍的改動。例如在已有「依姓名搜尋少年犯」需求的情況下，突然要求加入「依刺青照片搜尋」
• 釐清（Clarification）：協助團隊達成 Sprint 目標的額外細節。例如確認搜尋結果要依姓氏字母排序。Product Owner 應該在 Sprint 期間提供釐清

變更的經濟後果#

我們在產品待辦項目上的投資會隨狀態遞增：Ready（梳理）→ To Do（Sprint 規劃）→ Doing（執行中）→ Done（完成）。越晚變更，浪費越大：

• 即使尚未開始，也已投入規劃成本
• 功能之間可能有相依性，變更一個會連帶影響其他功能
• 已開始的工作可能全部報廢
• 除了直接經濟損失，還有團隊士氣與信任的間接影響

務實處理（Being Pragmatic）#

「不可變更目標」是規則，不是法律。Scrum 團隊必須務實。

若競爭對手在 Sprint 期間推出新產品，使目前的工作經濟價值大幅降低；或關鍵生產系統故障，唯有目前團隊能修復——這些情況下，堅持不變更是不合理的。

關鍵原則：以經濟合理性為依據做決策。若變更的經濟後果遠小於不變更的後果，就應該變更。

異常終止（Abnormal Termination）#

當 Sprint 目標完全失效時，可考慮異常終止 Sprint：

1. 立即結束目前 Sprint
2. 進行 Sprint Retrospective
3. 與 Product Owner 規劃下一個 Sprint（不同目標、不同待辦項目）

終止後有三個選項決定下一個 Sprint 長度：

1. 維持原長度：保持一致，但多團隊環境下會導致不同步
2. 縮短到原 Sprint 結束日：例如兩週 Sprint 在第一週終止，下一個 Sprint 只跑一週以重新同步
3. 延長覆蓋剩餘時間加下一個完整 Sprint：例如上述情況改跑三週的 Sprint

Sprint 終止應是最後手段。它會嚴重打擊士氣、破壞功能的快速靈活交付流程，並抵消一致長度 Sprint 的好處。由於 Sprint 很短，變更情況發生時通常已過半，很多時候只需做較小的調整（如移除某功能），而非終止整個 Sprint。

完成的定義（Definition of Done）#

每個 Sprint 的產出應是一個潛在可交付的產品增量（potentially shippable product increment）。「潛在可交付」不表示必須實際出貨，而是代表一種信心狀態——沒有實質上重要的未完成工作阻擋出貨。

什麼是 Definition of Done？#

Definition of Done 是一份團隊共識的檢查清單，列出團隊宣告工作「潛在可交付」前必須成功完成的工作類型，例如：

• 設計審查完成
• 程式碼完成（重構、格式化、註解、簽入、審查）
• 終端使用者文件更新
• 測試完成（單元測試、整合測試、回歸測試、平台測試、語言測試）
• 零已知缺陷
• 驗收測試通過
• 上線到生產伺服器

具體項目取決於產品性質、技術、組織，以及目前的阻礙。

若某些重要的測試（如效能測試）沒有每個 Sprint 執行，就必須在未來某個時候補做。這意味著你並未真正擁有每 Sprint 一個「潛在可交付」的產品增量。而且延後發現的問題修復成本更高。

Definition of Done 可以演進#

• 理想狀態：DoD 從開發初期就能達到「潛在可交付」，並在整個開發週期維持不變（例如每個 Sprint 結果都能上線到生產伺服器）
• 現實情況：許多團隊一開始有阻礙無法達到理想狀態，會從較低的完成標準開始，隨著阻礙移除逐步演進
  • 例如：臨床資訊系統團隊一開始沒有實驗室做臨床測試，後來取得大學實驗室的使用權後，將臨床測試納入 DoD
  • 例如：含硬體的產品在硬體到位前只能做「模擬器完成」（emulator done），硬體到位後才演進為真正的「潛在可交付」

Definition of Done vs. 驗收標準（Acceptance Criteria）#

這兩者是不同層級的概念：

一個產品待辦項目只有在同時滿足其專屬的驗收標準和 Sprint 層級的 Definition of Done 時，才算真正完成。

Done vs. Done-Done#

有些團隊區分「done」和「done-done」，但這其實反映了團隊尚未內化「完成就是真正完成」的心態。真正成熟的團隊不需要兩種狀態—— done 就意味著 done-done，即完成了所有讓客戶認為「做完了」的工作。