Sprint Planning 是每個 Sprint 的起點，Scrum 團隊在此活動中就 Sprint 目標達成共識，並決定在即將到來的 Sprint 中能交付什麼價值。本章說明 Sprint Planning 在 Scrum 框架中的定位及其執行方式。

概覽#

Product Backlog 可能包含數週甚至數月的工作量，遠超單一短期 Sprint 所能完成。Sprint Planning 的目的是從中挑選最重要的子集來開發：

活動說明
團隊協商 Sprint GoalProduct Owner 與 Development Team 協作決定目標
評估可交付範圍Development Team 根據目標選定對齊的 PBI
建立執行計畫將選定的 PBI 拆解為任務，取得完成信心
產出 Sprint Backlog選定的 PBI 加上執行計畫，共同組成 Sprint Backlog

Figure 19.1: When sprint planning happens

flowchart TD
    A[輸入準備\nBacklog + 速率 + 限制] --> B[評估團隊產能]
    B --> C{方法選擇}
    C -->|兩階段式| D["Part 1: 做什麼\nPart 2: 怎麼做"]
    C -->|單階段式| E[逐一選取與拆解]
    D --> F[選取 PBI 並拆解任務]
    E --> F
    F --> G[取得信心\n速度檢核 + 任務量檢核]
    G --> H{信心充足?}
    H -->|是| I[精煉 Sprint Goal]
    H -->|否| F
    I --> J[最終確認承諾]
    J --> K[產出 Sprint Backlog]

時間與頻率#

Sprint Planning 是一項即時（Just-in-time）、循環性的活動，在每個 Sprint 開始時進行，利用當下最佳資訊來決定接下來要做什麼。

  • 對於兩週到一個月的 Sprint，Sprint Planning 不應超過 4 到 8 小時

參與者#

完整的 Scrum 團隊都應參與 Sprint Planning：

角色職責
Product Owner分享初始 Sprint Goal、展示已排序的 Product Backlog、回答團隊疑問
Development Team評估交付能力、做出務實的承諾
ScrumMaster作為教練，觀察規劃過程、提出探究性問題、協助促進活動順利進行

ScrumMaster 不負責團隊的承諾決策，但可以挑戰團隊的承諾以確保其務實且恰當。

Sprint Planning 流程#

Figure 19.2: Sprint-planning activity

輸入項目#

Sprint Planning 仰賴以下關鍵輸入：

輸入說明
Product Backlog頂部項目已梳理至符合 Definition of Ready
團隊速度（Velocity）歷史速度作為團隊可完成工作量的指標
限制條件（Constraints）可能影響交付的商業或技術限制
團隊能力（Capabilities）成員組成、技能分布與可用時間
初始 Sprint GoalProduct Owner 希望本 Sprint 達成的商業目標

Product Owner 知道想要什麼，但不代表 Development Team 一定能在該 Sprint 內交付。務實的承諾只能透過 Product Owner 與 Development Team 之間的協作與協商來達成。

輸出項目#

Sprint Planning 的產出是最終確認的 Sprint Goal 與 Sprint Backlog（選定的 PBI 加上任務計畫）。

Sprint Planning 的兩種方法#

方法一：兩階段式（Two-Part）#

Figure 19.3: Two-part sprint-planning approach

分為兩個階段：

  1. Part 1「做什麼（What）」：Development Team 評估產能，預測本 Sprint 可完成的 PBI 數量（例如 40 個 story points 的工作量）
  2. Part 2「怎麼做（How）」：將 PBI 拆解為任務並估算工時，對比產能以驗證預測是否務實

如果發現選取太多或太少、或選取的項目因限制條件無法一起開發，團隊可調整預測並精煉 Sprint Goal，直到承諾落在合理的產能範圍內。

方法二：單階段式（One-Part）#

Figure 19.4: One-part sprint-planning approach

這是作者最常見的方式，交替進行選取項目與取得信心：

  1. Development Team 先評估產能
  2. 選取一個 PBI → 確認它能否放入 Sprint → 加入承諾
  3. 重複此循環直到產能用盡
  4. 最終確認承諾

評估產能（Determining Capacity）#

Figure 19.5: Development team capacity in a sprint

Sprint 的總時間並非全部可用於開發 PBI，需要扣除以下因素：

扣除因素說明
其他 Scrum 活動Sprint Planning、Sprint Review、Sprint Retrospective、Product Backlog Grooming（約 10% 時間）
非 Sprint 工作支援現有產品、維護其他系統等
個人休假-
Sprint 緩衝（Buffer）預留應對估算不準確或意外問題的空間

以 Story Points 表示產能#

  • 以團隊長期平均 Velocity 或上一 Sprint 的 Velocity（「昨天的天氣」法）作為初始估計
  • 根據即將到來 Sprint 的特殊情況進行調整（例如假期期間可能需要從 40 降到 20 story points）

以工時（Effort-Hours）表示產能#

團隊成員各自評估可用天數、扣除 Scrum 活動時間、再乘以每日可用工時：

人員可用天數扣除 Scrum 活動每日工時可用工時
Jorge1024-732-56
Betty825-630-36
Rajesh824-624-36
Simon922-314-21
Heidi1025-640-48
合計140-197

建議團隊不要把產能用到上限（如 197 小時），而是取一個合理的中間值，預留緩衝空間以因應意外狀況。

選取 Product Backlog Items#

選取 PBI 的原則：

原則說明
有 Sprint Goal 時選取與目標對齊的項目
沒有正式 Sprint Goal 時從 Product Backlog 頂端依序往下選取
不開始無法完成的工作若下一個 PBI 太大無法在 Sprint 內完成，應嘗試拆分或選擇其他可完成的項目
Definition of Ready可防止定義不清或有未滿足依賴的 PBI 被選入 Sprint

讓未完成的項目跨 Sprint 遞延，無法實現每個 Sprint 結束時都有潛在可交付產品增量的目標。啟動但未完成的工作會產生多種形式的浪費。

取得信心（Acquiring Confidence）#

  • 速度檢核：若預測 Velocity 為 25 story points 但團隊選了 45 points，就需要質疑承諾的可行性
  • 任務拆解：大多數團隊透過將 PBI 拆解為任務（通常以工時估算），來取得更深層的信心

Figure 19.6: Sprint backlog showing PBIs and task plan

範例分析#

假設團隊選取了 4 個 PBI（共 21 story points），拆解後總計 150 工時，而團隊產能為 140-197 工時。150 小時落在合理範圍內，看似安全。

但數字匹配不等於承諾合理——還需考慮技能容量（Skills Capacity）：

  • 若 Simon 是唯一能做 UI 工作的人，而他每天只有 2-3 小時，Sprint 內只有 14-21 可用工時
  • 即使總工時充足，也可能在特定技能領域出現「產能瓶頸」

有些團隊會在任務上標記最可能負責的人選，但這可能削弱團隊對任務的集體所有權。較好的策略是讓成員在 Sprint 執行期間以即時、機會導向的方式自行選擇任務。

精煉 Sprint Goal#

  • Product Owner 應帶著初始 Sprint Goal 進入 Sprint Planning
  • 在規劃過程中，隨著團隊評估實際可交付範圍，Sprint Goal 可以被精煉與調整

最終確認承諾#

Sprint Planning 結束時，Development Team 最終確認其對 Sprint 商業價值的承諾：

  • Sprint Goal 與選定的 PBI 共同體現這項承諾
  • 無論偏好使用 commitment 還是 forecast 一詞，Sprint Planning 的方法都是相同的
  • 這兩個詞的細微差異可能影響團隊決定交付範圍的方式，以及在 Sprint 執行期間如何因應新資訊
Backward Release Planning (Longer-Term Planning) Sprint Execution Forward