迭代規劃的目的#
迭代規劃（Iteration Planning）決定團隊在這個迭代中要做哪些 Story，以及如何將 Story 拆解為具體的開發任務（Task）。
從 Story 到 Task#
Story 描述的是使用者看到的功能，而 Task 描述的是開發人員需要做的具體工作。例如：
Story：「使用者可以依作者搜尋書籍」
Tasks：
- 設計搜尋結果頁面的 UI（4 小時）
- 撰寫搜尋的 SQL 查詢（2 小時）
- 建立搜尋結果的分頁功能（3 小時）
- 撰寫單元測試（2 小時）
Task 用理想小時（Ideal Hours）估算，而非 Story Point。理想小時是在沒有任何干擾下完成工作所需的時間。
迭代規劃會議#
迭代規劃會議通常分為兩個部分：
前半段：選擇 Story#
- 客戶說明最高優先的 Story
- 開發人員提問以釐清細節
- 團隊決定本次迭代可以承諾完成多少 Story
後半段：拆解 Task#
- 針對每個選中的 Story，團隊拆解為具體的 Task
- 開發人員認領 Task
- 用理想小時估算每個 Task
速度驅動 vs. 承諾驅動#
兩種決定迭代工作量的方式：
- 速度驅動：根據歷史速度，選擇等量的 Story Point
- 承諾驅動：逐一將 Story 拆解為 Task，累加工作時數，直到團隊認為已滿
在初期團隊還沒有穩定的速度數據時，適合使用承諾驅動的方式。一旦有了幾次迭代的數據，就可以切換為速度驅動。
避免常見錯誤#
- 不要把 Task 指派給特定的人：讓開發人員自行認領，促進團隊自組織
- 不要追求精確的小時估算：估算是為了判斷「大概能做多少」，不是精確的專案管理
- 不要在迭代中途加入新 Story：除非團隊提前完成了所有工作
迭代的工作範圍一旦確定，就不應在迭代進行中隨意變更。如果需求變動過大，寧可中止當前迭代並重新規劃。