規劃是 Scrum 團隊不可或缺的技能。早期敏捷運動中「我們不做計畫」的口號是對傳統文化的過度反應——計畫經常被拿來當作武器對付開發者。事實上，根據研究，敏捷團隊的規劃往往比使用順序式流程的團隊更為準確。本章探討如何超越 Sprint 與 Release 規劃的基本功，處理更進階的規劃挑戰。
漸進式細化計畫（Progressively Refine Plans）#
好的 Scrum 團隊對規劃的態度與對 Product Backlog 的態度相同：漸進式細化。就像 Epic 先描述功能的本質，之後再逐步拆解為更小的 User Story，早期的計畫也應該只捕捉大方向，隨著專案推進再補充細節。
例如，一個網路族譜產品團隊有六個月的死線。對於最高優先級的功能（如手動繪製族譜），計畫可以包含很多細節；但對於較低優先級的功能，可能只寫一句 User Story，如「身為使用者，我想上傳照片並附加到族譜中的人物上」，留待後續再決定要支援哪些圖片格式。
漸進式細化的好處#
- 最小化時間投資：規劃是一種投資，過早投入大量時間做細節規劃，往往因為假設錯誤而白費
- 在最佳時機做決策：延遲決策讓團隊在擁有更多知識時再做判斷，避免過早鎖定方向
- 允許中途修正：只規劃大方向而非所有細節，讓團隊在學到新東西時有彈性調整的空間
- 避免陷入「相信計畫」的陷阱：一份過於完整的計畫會讓人誤以為一切都已考慮周全；漸進式細化提醒我們，即使最好的計畫也可能需要改變
不要靠加班來挽救計畫（Don’t Plan on Overtime to Salvage a Plan）#
延長加班是一種常見但效果遞減的手段。作者回憶自己早年管理非 Scrum 團隊的經歷：起初讓開發者偶爾加班確實有效，但幾個月後，加班越來越多卻越來越沒用——之前趕工時走的捷徑開始反噬，Bug 越來越多。
Extreme Programming 將此原則稱為 sustainable pace（可持續步調）：團隊大部分時間保持穩定節奏，偶爾在接近里程碑時加速衝刺是可以的，但持續多週的加班是一種警訊。Kent Beck 和 Cynthia Andres 指出：「加班是專案嚴重問題的徵兆。規則很簡單——你不能連續加班兩週。」
High Moon Studios 的教訓#
遊戲開發商 High Moon Studios 的 CTO Clinton Keith 在年度 E3 展前要求團隊強制加班。第一週 velocity 確實上升，但第二週已經低於第一週，第三週幾乎與加班前持平，到了第四週，velocity 竟然低於原本的可持續步調。
Figure 15.1: High Moon Studios found that subsequent weeks of overtime actually lowered velocity
可持續步調 vs. 不可持續步調#
以可持續步調工作的團隊，每個時間段完成的工作量一致。以不可持續步調工作的團隊，雖然某些時段產出超高，但其他時段因為恢復期而產出驟降。關鍵問題是：可持續步調曲線下方的面積，是否大於不可持續步調曲線下方的面積？ 就像跑五公里，用穩定配速跑會比全力衝刺加上走路交替來得快。
Figure 15.2: The amount of work completed is shown by the area under each line
說服組織的論點#
- 保留額外產能以應對真正需要的時刻：如果團隊總是全力衝刺，當真正需要加速時就沒有餘力了
- 為創造力留出空間：真正的生產力不只來自更多工時，也來自偶然迸發的創意方案
- 別再說「大腦六小時就耗盡了」：高階主管每天工作 12 小時以上，用「腦力有限」的說法說服不了他們；改用數據說話更有效
- 值得一試：在專案早期收集可持續步調下的 velocity 數據，當加班被強制要求時，嘗試協商只在數據證明 velocity 有所提升的前提下繼續
如果不靠加班，那怎麼辦？#
Tony Schwartz 和 Catherine McCarthy 提出了解方：時間是有限的，但精力（energy）可以增加。透過以下方式提升團隊精力：
- 增加熱情（passion）——Product Owner 傳達引人入勝的產品願景，讓團隊成員對工作充滿熱忱
- 定期休息恢復精力——作者自己用 30 分鐘為一單位的寫作衝刺；Francesco Cirillo 的 Pomodoro 技法也是類似做法（25 分鐘專注 + 5 分鐘休息，每四輪休息 15-30 分鐘）
優先調整範圍（Favor Scope Changes When Possible）#
專案管理學會（PMI）長期使用「鐵三角」（Iron Triangle）來表達 Scope、Resources 和 Schedule 之間的相互依存關係。品質被放在三角形中心，理想上不可觸碰，但實務中品質往往成為第四個被犧牲的維度。
Figure 15.3: The iron triangle illustrates the relationship between scope, resources, and schedule
轉型到 Scrum 的組織需要學會：當無法如期完成所有功能時，調整範圍應該是首選。
逐一考量各種替代方案#
假設一個預計 12 個月的專案，在第 9 個月時發現無法按時交付全部範圍：
- 削減品質？ 短視近利。Philip Crosby 在 1979 年就指出「品質是免費的」，真正花錢的是「不把事情一次做對」。走捷徑反而會因返工和不穩定性而拖慢進度。而且很難預測削減品質的實際影響——要少測哪些？少測多少？
- 增加人手？ Fred Brooks 在 The Mythical Man-Month 中警告：「向一個遲到的軟體專案增加人力，只會讓它更遲。」在專案後期加人，訓練成本和溝通開銷往往抵消新人帶來的產出，且影響不可預測。
- 延長時程？ 對開發團隊來說最容易，但對業務端往往不可行——客戶承諾、廣告計畫、招募的支援人員等都已就位。當延長時程可行時，仍應被考慮。
- 調整範圍？ 如果團隊一直按優先級工作，被砍掉的會是最低優先級的功能。雖然令人失望，但這通常是在時間和團隊有限的情況下，能交付的最佳產品。
專案情境是關鍵#
作者並非主張範圍永遠是第一個調整的選項，但希望組織認識到調整範圍往往比想像中更可行，而且通常是鐵三角中最好的調整面向。
如果產品確實有不可刪減的必要功能（就像汽車不能沒有引擎和煞車），無法只靠縮減範圍來趕上死線，那就該考慮其他方案——包括延長時程，甚至取消專案。真正的問題往往是計畫本身缺乏足夠的安全邊際。
將估算與承諾分開（Separate Estimating from Committing）#
許多組織的根本問題是：估算（Estimate）被等同於承諾（Commitment）。「我們估計這需要七個月」被傳遞為「我們承諾七個月內完成」——中間可能還被層層削減以提供「挑戰性目標」。估算和承諾都很重要，但它們應該是兩個獨立的活動。
正確的數據基礎#
要做出好的估算，Product Owner 和團隊需要兩個關鍵數據：
- 工作的規模——使用 Story Points 或 Ideal Days 對 Product Backlog 項目進行估算
- 團隊的預期進度速率——即 Velocity（每個 Sprint 完成的 Story Points 總和，通常不計算部分完成的項目）
使用信賴區間（Confidence Interval）#
Velocity 會在 Sprint 之間波動（就像球隊每場得分不同），因此不應過度依賴單一數值。作者建議使用 90% 信賴區間來預測未來 velocity 的範圍：
- 收集至少 5 個 Sprint 的歷史 velocity 數據
- 將數值從低到高排序
- 利用查表法找出 90% 信賴區間的邊界值（例如 9 個觀測值取排序後第 2 低和第 2 高的值）
- 將信賴區間乘以剩餘 Sprint 數，即可預測團隊可能完成的工作範圍
例如，一個團隊 9 個 Sprint 的 velocity 排序後為：27, 34, 35, 38, 39, 40, 40, 41, 45。90% 信賴區間為 34 到 41。如果剩下 5 個 Sprint，團隊可能完成 170（5 x 34）到 205（5 x 41）Story Points 之間的工作量。
Figure 15.4: Predicting the amount of work to be completed
從估算到承諾#
信賴區間提供的是估算範圍，而非承諾。將範圍轉換為承諾時需要考慮商業情境：
- 承諾下限（如 170 點）：幾乎一定能達成，但對方可能不滿意數字太低——這是用長期風險換取短期安全
- 承諾上限（如 205 點）：讓當下的人滿意，但有很大機率無法兌現——這是用短期讚美換取長期風險
最理想的承諾方式是提供一個範圍：「我們承諾在接下來 5 個 Sprint 交付 170 到 205 個 Story Points 之間的工作。」
沒有歷史數據時怎麼辦#
全新團隊：最好先跑 1-2 個 Sprint 再做承諾。如果不行，可以找一群技能相似的人模擬 Sprint Planning——從 Product Backlog 中逐一挑選 User Story，拆解任務並以小時估算，看看一個 Sprint 能承諾多少。將選中的 User Stories 的 Story Points 加總，即為初始 velocity 估算值。可用直覺上下調整 25%，或使用其他團隊的相對標準差來建立範圍。
團隊規模經常變動：收集每次團隊人數變動後，前幾個 Sprint 的 velocity 變化百分比。數據顯示，即使增加人手，velocity 在第一個 Sprint 幾乎必然下降（因溝通成本增加、新成員需要時間融入等），通常到第三個 Sprint 後才能看到長期影響。
利用這些數據可以回答各種問題：增加兩個人會怎樣？每個團隊各加一人能提早多少完成？裁員 15% 的影響是什麼？
開始收集與你的情況相關的數據：至少用試算表追蹤每個團隊每個 Sprint 的 velocity。如果團隊規模經常變動，也納入追蹤。數據累積足夠後，開始製作類似 Figure 15.4 的圖表，幫助 Product Owner 做範圍與時程的取捨決策。
小結#
精通規劃是每個 Scrum 團隊的關鍵技能。本章探討了以下進階規劃策略：
- 漸進式細化計畫——避免過早做出過於詳細的計畫
- 以可持續步調工作——加班不是解方，反而會降低長期生產力
- 優先調整範圍——當無法按時完成一切時，調整範圍通常是最佳選項
- 將估算與承諾分開——使用信賴區間提供誠實且有數據支撐的承諾