Sprint Execution 是 Scrum 團隊為達成 Sprint Goal 而進行的實際工作。本章聚焦於指導團隊在 Sprint 執行期間如何規劃、管理、執行與溝通的原則與技術。

概覽#

Sprint Execution 就像一個迷你專案——所有產出潛在可交付產品增量（Potentially Shippable Product Increment）所需的工作都在此完成。

Figure 20.1: When sprint execution happens

時間#

  • Sprint Execution 佔 Sprint 中的大部分時間
  • 始於 Sprint Planning 結束後，終於 Sprint Review 開始前
  • 在兩週的 Sprint 中，Sprint Execution 大約佔 10 天中的 8 天

參與者#

角色職責
Development Team自組織，決定達成 Sprint Goal 的最佳方式
ScrumMaster作為教練、促進者與障礙移除者；不分配工作、不告訴團隊怎麼做
Product Owner回答澄清問題、審查中間產出並提供回饋、必要時討論 Sprint Goal 調整、驗證驗收條件是否滿足

Sprint 執行流程#

Figure 20.2: Sprint execution activity

  • 輸入：Sprint Goal 與 Sprint Backlog
  • 輸出：潛在可交付產品增量（每個項目都符合 Definition of Done）
  • 核心活動：任務規劃、流程管理、任務執行、溝通

Sprint 執行中的規劃#

雖然團隊在 Sprint Planning 時已產出 Sprint Backlog（含 PBI 及其任務估算），但不應嘗試建立完整的前期計畫（如甘特圖）：

  • 5-9 人的小團隊在短期 Sprint 中不需要甘特圖來規定誰做什麼
  • 即使建立了完整計畫，Sprint Execution 的大量學習很快就會讓它過時
  • 適度的前期規劃仍有價值（如識別重要的任務級依賴關係）

Sprint Execution 的最佳原則是機會導向的任務規劃——允許規劃在 Sprint 執行過程中隨著環境變化持續發生，而非一開始就制定完整計畫。

流程管理（Flow Management）#

團隊必須自行管理 Sprint 內的工作流程：決定同時進行多少工作、何時開始新項目、如何組織任務、誰來執行。

平行工作與蜂擁（Swarming）#

Figure 20.3: Cost of multitasking

多工處理的代價非常高：

  • 一個簡單的字母/數字/羅馬數字實驗顯示，逐列完成（多工）平均 35 秒，逐欄完成（單一任務）平均僅 16 秒
  • 錯誤也集中出現在多工模式中
  • 在複雜專案工作中，多工的浪費更為嚴重

Swarming（蜂擁） 是指有可用產能的團隊成員聚集在已開始的項目上，先完成已啟動的工作再開始新項目：

  • 目標是在不超載 T 型技能和可用產能的前提下，減少個別項目的完成時間
  • Swarming 不是為了讓所有人 100% 忙碌——那只會造成更多多工
  • 擁有 Musketeer 態度和 T 型技能的團隊會蜂擁；仍以個人角色思考的團隊則會出現「我寫完 code 了，測試是你們的事」的現象

避免 Mini Waterfall！ 不要在 Sprint 中同時開始所有 PBI 然後依序「分析全部 → 設計全部 → 編碼全部 → 測試全部」。如果最後時間不夠完成測試，就沒有任何一個項目是「Done」，Product Owner 得不到任何經濟價值。

Figure 20.4: Mini waterfall during sprint execution — a bad idea

flowchart TD
    subgraph good["Swarming（好的做法）"]
        direction LR
        A1[選取 PBI-1] --> A2[團隊蜂擁完成]
        A2 --> A3[選取 PBI-2]
        A3 --> A4[團隊蜂擁完成]
        A4 --> A5[逐一完成所有 PBI]
    end

    subgraph bad["Mini Waterfall（壞的做法）"]
        direction LR
        B1[同時開始\n所有 PBI] --> B2[全部分析]
        B2 --> B3[全部設計]
        B3 --> B4[全部編碼]
        B4 --> B5[全部測試]
        B5 --> B6[可能無一完成]
    end

選擇下一個工作項目#

  • 最簡單：選擇 Product Owner 指定的下一個最高優先項目
  • 實際中：技術依賴或技能產能限制可能要求不同的選取順序
  • Development Team 需要有權依實際狀況機會導向地做出選擇

如何組織任務工作#

  • 避免對單一 PBI 套用瀑布思維（先分析 → 再設計 → 再編碼 → 再測試）
  • 採用價值交付導向的思維：成員機會導向地組織任務、最小化工作閒置時間
  • 例如：兩人搭檔在 Sprint 第一天即快速循環「建立測試 → 撰寫程式碼 → 執行測試 → 精煉」

要做什麼工作？#

  • 團隊自行決定任務級別的工作內容
  • Product Owner 定義功能範圍與驗收條件，提供商業面的 Definition of Done 要求
  • 團隊與 Product Owner 討論經濟上合理的取捨——過度打磨可能不值得，偷工減料則會累積技術債

誰來做工作？#

  • 明顯答案是最能快速正確完成的人
  • 當團隊具備 T 型技能時，多人都有能力承接每個任務
  • 團隊集體考量各種因素，做出好的選擇

Daily Scrum#

Daily Scrum 是一項每日檢視與調適的關鍵活動：

  • 時間箱：15 分鐘
  • 目的：同步資訊、分享全局、集體理解工作進度、避免等待
  • 頻率：每 24 小時一次——如果改為每週一次，團隊就失去了快速回饋的好處
  • 對流程管理至關重要

技術實踐（Technical Practices）#

Figure 20.5: Subset of Extreme Programming technical practices

在短時間箱中交付潛在可交付產品增量，對團隊的技術能力提出了要求。關鍵的 Extreme Programming 技術實踐包括：

  • Test-Driven Development（TDD）
  • Refactoring（重構）
  • Simple Design（簡單設計）
  • Pair Programming（結對程式設計）
  • Continuous Integration（持續整合）
  • Collective Code Ownership（集體程式碼所有權）
  • Coding Standard（編碼規範）

不自動化測試的團隊將很快減速並承擔越來越大的風險。到某個時點，整個 Sprint Execution 時間可能都用於手動重跑迴歸測試。不開始自動化測試，就不可能長期保持敏捷。

溝通（Communicating）#

短時間箱配合小團隊的好處之一是不需要複雜的圖表和報告來溝通進度。大多數團隊使用以下工具組合作為主要的資訊輻射器（Information Radiator）。

Task Board（任務板）#

Figure 20.6: Example task board

  • 直觀展示 Sprint Backlog 隨時間演進的狀態
  • 每個 PBI 配有其任務，任務在 To Do → In Progress → Completed 之間流動
  • 團隊可自訂欄位以視覺化更多工作狀態（類似 Kanban 看板的詳細看板）

Sprint Burndown Chart（Sprint 燃盡圖）#

Figure 20.7: Sprint burndown chart

  • 縱軸：剩餘估計工時（effort-hours remaining）
  • 橫軸：Sprint 內的天數
  • 每天更新所有未完成任務的剩餘工時
  • 新任務可在 Sprint 中隨時加入 Sprint Backlog（反映對工作的更深理解，不是引入新範圍的漏洞）

Figure 20.8: Sprint burndown chart with trend lines

透過趨勢線可預測工作完成時間：

趨勢說明
On time趨勢線在 Sprint 結束時接近水平軸
Early趨勢線明顯偏左，可考慮承接額外工作
Late趨勢線明顯偏右，需要深入調查原因

Sprint Backlog 和 Sprint Burndown Chart 始終使用剩餘估計工時，不記錄實際耗費工時。Scrum 本身不需要記錄實際值，但組織可能因成本會計或稅務等原因選擇這樣做。

Sprint Burnup Chart（Sprint 燃起圖）#

Figure 20.9: Sprint burnup chart

Sprint Burnup Chart 展示已完成工作向目標的進展：

  • 可用工時或 Story Points 表示（許多人偏好後者，因為最終重要的是已完成的商業價值）
  • 能直觀反映工作流動狀況——「Bad flow」曲線顯示同時開始太多項目、延遲完成的後果
  • 對比「Good flow」與「Bad flow」可清楚看出流程管理的影響
Backward Sprint Planning Sprint Review Forward