User Story 源自 Extreme Programming（XP），但同樣能完美融入 Scrum 流程。本章介紹 Scrum 的基本概念，以及如何將 Story 整合到 Scrum 的各個環節。
Scrum 基礎概念#
迭代與增量#
Scrum 同時是迭代式和增量式的開發流程：
- 迭代式：透過多次循環逐步精煉產品，每次迭代改善已有的功能
- 增量式：每次交付完整且可用的功能片段，逐步累積成完整產品
核心結構#
Scrum 的運作圍繞以下幾個核心元素：
- Sprint：通常為 30 天的固定時間區間
- Product Backlog：所有期望功能的優先順序清單
- Sprint Backlog：本次 Sprint 團隊承諾完成的任務清單
- Daily Scrum：每天 15 分鐘的站立會議
關鍵角色#
- Product Owner：對應 XP 的客戶角色，負責管理和排序 Product Backlog
- ScrumMaster：服務型領導者，協助團隊遵循 Scrum 規則、移除障礙
- 開發團隊：通常 4-7 人的自組織團隊
ScrumMaster 的角色是服務和引導，而非管理和指揮。團隊自行決定如何完成工作。
Figure 15.1: Graphical representation of the Scrum process
將 Story 整合到 Scrum#
Story 與 Product Backlog#
將 Product Backlog 的項目限定為 User Story，而非混雜技術任務、bug 和需求：
- 每個 Story 都描述對使用者或 Product Owner 有價值的功能
- Product Owner 更容易理解和排序
- 團隊更容易討論和權衡取捨
Story 與 Sprint Planning Meeting#
Sprint Planning Meeting 分兩部分：
- 前半段：Product Owner 說明最高優先的 Story，團隊提問
- 後半段：團隊決定能承諾多少工作，並將 Story 拆解為 Task
Story 讓每個 Backlog 項目都傳達使用者價值，使 Sprint Planning 更高效。
Story 與 Sprint Review Meeting#
在 Sprint Review 中展示完成的 Story 比展示技術任務更直觀。當 Backlog 全部由 Story 組成時，更容易驗證每個項目是否真的完成。
Story 與 Daily Scrum#
Story 幫助團隊在每日站會中保持對客戶價值和使用者需求的關注。每位成員回答三個問題：
- 昨天完成了什麼？
- 今天計畫做什麼？
- 有什麼障礙？
案例研究#
一個曾以瀑布式開發耗時 9 個月（100 人團隊、540 人月、58,000 行程式碼）的專案，改用 Scrum + Story 後，7 人團隊在 12 個月內完成（54 人月、51,000 行程式碼），每人月產出程式碼從 120 行提升至 840 行。
Scrum 的核心規則#
- Sprint Planning Meeting 在每個 Sprint 開始時舉行
- 每個 Sprint 必須交付可運行、經測試的程式碼
- Product Owner 負責排序 Product Backlog
- Sprint 開始後，只有團隊可以加入工作到 Sprint Backlog
- Sprint Review 中只展示可運作的軟體，不用投影片