結論先講
一個好的 Sprint 有明確的 Goal、合理的容量、最少的依賴、以及每個人都知道「做完」長什麼樣。Sprint Planning 不是把 backlog 最上面的 ticket 丟進去直到塞滿——是圍繞一個目標挑選最重要的工作，並確保團隊有能力在時間內完成。
Sprint Goal：一句話定義成功
Sprint Goal 是整個 Sprint 最重要的東西，但也是最常被跳過的。
好的 Sprint Goal
「這個 Sprint 結束時，使用者可以完成從加入購物車到信用卡付款的完整結帳流程。」
壞的 Sprint Goal
「完成 Jira 上面排的 12 張 ticket。」
差別在哪？好的 Sprint Goal 描述交付的價值，壞的只是列出工作量。
為什麼 Sprint Goal 重要
- 決策依據：Sprint 中間有事情要取捨時，問「這對達成 Sprint Goal 有幫助嗎？」
- 團隊凝聚力：大家朝同一個目標努力，不是各做各的
- 對外溝通：跟利害關係人說「這個 Sprint 我們要交付結帳功能」比說「我們要做 12 張 ticket」清楚得多
Sprint Goal 寫法公式
為了 [商業目的]，我們要讓 [使用者] 能夠 [做什麼]。
例如：
- 「為了上線前的最後準備，我們要讓管理員能夠從後台管理商品庫存。」
- 「為了降低客訴，我們要修復結帳流程中的三個關鍵 bug。」
容量計算
基本公式
Sprint 容量 = 可用人天 × Focus Factor
算可用人天
| 成員 | 工作天 | 請假 | 可用天數 |
|---|---|---|---|
| 小明 | 10 | 0 | 10 |
| 小華 | 10 | 2（特休） | 8 |
| 小李 | 10 | 0 | 10 |
| 小林 | 10 | 1（看診） | 9 |
| 總計 | 37 人天 |
Focus Factor
Focus Factor 是「實際能專注在 Sprint 工作上的比例」。
| 情境 | Focus Factor |
|---|---|
| 專職產品開發，很少會議 | 0.7-0.8 |
| 產品開發 + 偶爾維運 | 0.6-0.7 |
| 產品 + 維運 + 大量會議 | 0.4-0.6 |
以上面的例子：37 人天 × 0.7 = 25.9 人天的實際產能
用 Story Points 算
如果你用 SP，更簡單：看前三個 Sprint 的平均 velocity。
| Sprint | 完成 SP |
|---|---|
| Sprint 5 | 24 |
| Sprint 6 | 26 |
| Sprint 7 | 22 |
| 平均 | 24 SP |
下一個 Sprint 就承諾 24 SP 左右。不要因為這次感覺士氣好就承諾 30——數據不會騙人。
什麼該放進 Sprint，什麼不該
該放進去的
- 有助於達成 Sprint Goal 的 stories
- 已經 grooming 過、有 AC 和估算的 ticket
- 依賴已解決或確認在 Sprint 期間能解的
不該放進去的
- 估算超過 Sprint 容量一半的單一 ticket（太大，先拆）
- 有未解的依賴（「等設計稿」「等第三方 API 權限」）
- 「想做」但跟 Sprint Goal 無關的項目
- 還沒精煉的模糊需求
經驗法則
Sprint 容量的 80-85% 排計畫內的工作，留 15-20% 給意外（bug、生產問題、臨時需求）。如果你排 100%，任何一個意外都會讓 Sprint 爆掉。
依賴管理
跨團隊的依賴是 Sprint 炸裂的常見原因。
依賴類型
| 類型 | 範例 | 處理方式 |
|---|---|---|
| 團隊內部 | 前端等後端 API | 先做 API，或用 mock |
| 跨團隊 | 我們等設計團隊的設計稿 | Sprint Planning 前確認交付時間 |
| 外部 | 等第三方 API 審核 | 提前申請，不要放進 Sprint 直到確認 |
依賴處理原則
- 盡量消除依賴：改用 mock、自己做簡單版設計
- 不能消除就提前確認：Sprint Planning 前跟對方確認交付時間
- 有風險就不要排：如果依賴解不開的機率超過 30%，別排進 Sprint
處理中途插單
PM：「客戶反映了一個很嚴重的 bug，我們需要這個 Sprint 修。」 老闆：「老闆的老闆說要加這個功能。」
中途插單不可避免，但你可以管理它。
決策框架
插單需求進來
│
▼
是 P0/P1 bug？ ──── 是 → 直接處理，Sprint 容量自動扣除
│
否
▼
跟 Sprint Goal 有關？ ── 是 → 評估後放入，拿掉等量的 ticket
│
否
▼
可以等到下個 Sprint？ ── 是 → 放入 Backlog 頂端
│
否
▼
放入，但拿掉等量 ticket，並記錄 scope change
關鍵原則：等量交換
進一個就要出一個。 如果 PM 要加一張 3 SP 的 ticket，就要拿掉至少 3 SP 的其他 ticket。不是「團隊再努力一下就好了」——容量是固定的。
記錄 Scope Change
每次中途插單都要記錄：
| 日期 | 加入 | 移除 | 理由 | 決策者 |
|---|---|---|---|---|
| Day 3 | BUG-123（3 SP） | FEAT-456（3 SP） | 客戶回報金流錯誤 | PO |
| Day 7 | FEAT-789（5 SP） | FEAT-012, FEAT-013 | 老闆要求 | CEO |
累積這些數據，你就有跟管理層溝通的彈藥：「過去三個 Sprint，平均每個 Sprint 有 20% 的 scope change，這就是我們每次做不完的原因。」
Definition of Done（DoD）
DoD 是團隊對「做完」的共同標準。沒有 DoD，每個人的「做完」不一樣：
- 小明的「做完」：code 寫好，可以跑
- 小華的「做完」：code 寫好、測試寫好、code review 過了
- 小李的「做完」：以上全部 + 文件更新 + deploy 到 staging
建議的 DoD 檢查表
- Code 已通過 code review
- 單元測試已撰寫，覆蓋率達到團隊標準
- 整合測試已通過
- 符合所有 Acceptance Criteria
- 文件已更新（如有需要）
- 已 deploy 到 staging 環境
- PO 已驗收
DoD vs AC
| Definition of Done | Acceptance Criteria | |
|---|---|---|
| 範圍 | 所有 ticket 都適用 | 每個 ticket 各自不同 |
| 誰定 | 團隊共同決定 | PO 和團隊一起寫 |
| 範例 | 「所有 code 要有 test」 | 「使用者選超商後顯示門市選擇器」 |
Sprint Review vs Retrospective
這兩個常常被搞混，但目的完全不同。
| Sprint Review | Sprint Retrospective | |
|---|---|---|
| 目的 | 展示成果、收集回饋 | 改善團隊流程 |
| 參與者 | 團隊 + 利害關係人 | 只有團隊 |
| 討論什麼 | 做了什麼、學到什麼、接下來做什麼 | 什麼做得好、什麼要改善 |
| 產出 | 回饋、調整 Backlog | 2-3 個改善行動 |
| 時間 | Sprint 結束時 | Review 之後 |
Sprint Review 實戰建議
- Demo 用活的系統，不是投影片
- 讓利害關係人親手操作，而不是你操作給他看
- 主動問回饋：「這個流程跟你想的一樣嗎？有什麼地方需要調整？」
- 記錄回饋但不當場承諾：「收到，我們會評估放進 Backlog」
Sprint Retrospective
Retro 是系列第八篇的主題，這裡先講核心：
- 一定要有 action items，而且要有負責人和期限
- 上次的 action items 這次要追蹤進度
- 營造安全感——人不舒服就不會說真話
Sprint Planning 會議流程模板
| 步驟 | 時間 | 活動 | 負責人 |
|---|---|---|---|
| 1 | 10 分鐘 | 回顧上個 Sprint（velocity、scope change） | SM |
| 2 | 10 分鐘 | PO 提出 Sprint Goal | PO |
| 3 | 5 分鐘 | 確認團隊容量（請假、維運） | SM |
| 4 | 30 分鐘 | 選擇 stories、討論 AC、確認估算 | 全團隊 |
| 5 | 10 分鐘 | 確認依賴和風險 | 全團隊 |
| 6 | 5 分鐘 | 總結承諾、確認 Sprint Goal | SM |
總計：70 分鐘（兩週 Sprint 的建議時長）
常見錯誤
1. 沒有 Sprint Goal
團隊只是把 ticket 丟進 Sprint，沒有方向感。結果 Sprint 結束時做了一堆零散的東西，沒有一個完整的功能可以 demo。
2. 承諾太多
每次都覺得「這次可以做更多」，然後每次都做不完。結果團隊士氣越來越低，velocity 越來越不準。
3. 不留 buffer
Sprint 排 100% 的容量，任何一個意外（請假、bug、需求變更）都會讓 Sprint 失敗。
4. Sprint Planning 變成 grooming
花兩小時在討論需求細節——這應該在 grooming 時做好。Planning 時 ticket 應該已經精煉過了。
FAQ
Q1：Sprint 應該多長？
大多數團隊用兩週。一週太短（花太多時間在儀式上），四週太長（失去迭代的意義）。新團隊建議從兩週開始，穩定後再決定要不要調整。
Q2：Sprint 期間可以加 ticket 嗎？
可以，但要遵守等量交換原則。P0 bug 例外——直接處理，容量自動扣除。如果每個 Sprint 都有大量插單，問題不在 Sprint，在需求管理。
Q3：Sprint 做不完怎麼辦？
未完成的 ticket 回到 Backlog 頂端，下個 Sprint 優先排入。不要延長 Sprint。在 Retro 裡討論為什麼做不完——是估算太樂觀？還是插單太多？還是依賴沒解決？
Q4：一個人可以同時參與兩個團隊的 Sprint 嗎？
盡量避免。一個人跨兩個 Sprint，Focus Factor 直接砍半，而且上下文切換的成本比你想的高。如果不得已，在兩邊的 Sprint Planning 都要明確說清楚容量只有 50%。
Q5：Sprint 結束時 PO 不驗收怎麼辦？
先確認 DoD 定義裡 PO 驗收是不是必要條件。如果是，那 ticket 就不算 Done。在 Retro 裡討論這個問題，找出 PO 不驗收的原因——是太忙？還是覺得不重要？然後找解法（例如每天花 15 分鐘驗收，而不是累積到 Sprint 結束）。