概述#

Release Planning（發布規劃）是一種長期規劃，幫助我們回答以下問題：

• 「我們什麼時候能完成？」
• 「到年底我能得到哪些功能？」
• 「這會花多少錢？」

Release planning 必須在客戶價值與整體品質之間取得平衡，同時兼顧範疇（scope）、時程（schedule）與預算（budget）的限制。

發布節奏（Release Cadence）#

組織必須決定適合的發布節奏，常見模式有三種：

• 多個 Sprint 後發布 — 結合數個 Sprint 的成果為一次發布
• 每個 Sprint 發布 — Sprint 結束即發布該 Sprint 的潛在可交付增量
• 每個功能即發布（Continuous Deployment） — 功能完成就發布，可能一天數次

無論採用哪種模式，大多數組織都認為某種程度的長期、高層級規劃是有用的。

如果 “release planning” 這個名稱不適合你的情境，可以使用同義詞如 longer-term planning（長期規劃） 或 milestone-driven planning（里程碑驅動規劃）。

時機#

Release planning 不是一次性事件，而是每個 Sprint 都會頻繁進行的活動：

• 初始 release planning 在 envisioning 之後進行，通常持續一兩天
• 隨著每個 Sprint 獲得已驗證的學習，持續更新 release plan
• 可在 Sprint Review 中或準備下一個 Sprint 時修訂

參與者#

Release planning 涉及利害關係人與完整 Scrum 團隊的協作，因為需要做出商業與技術的取捨。

流程#

輸入：

• 產品願景、高層級 product backlog、產品路線圖（來自 envisioning）
• 團隊的速率（velocity）

關鍵活動：

輸出（Release Plan）：

• 何時完成、能得到哪些功能、成本多少
• 明確的 MRFs 定義
• Product backlog items 到 Sprint 的初步對應

發布限制（Release Constraints）#

Release planning 的目標是決定什麼構成最有價值的下一次發布，以及期望的品質水準。範疇、日期和預算是影響如何達成目標的重要變數。

flowchart TD
    A{範疇與日期\n都能固定?} -->|是| B["Fixed Everything\n全部固定（不建議）"]
    A -->|否| C{哪個更重要?}
    C -->|日期| D["Fixed Date\n固定日期（最推薦）"]
    C -->|範疇| E["Fixed Scope\n固定範疇"]
    C -->|都重要| F["Fixed Scope + Date\n（不建議，Chicken Game）"]

Fixed Everything — 全部固定（不建議）#

在 Scrum 中，我們不相信能在一開始就把所有事情都搞對，因此至少需要一個變數是彈性的。

Fixed Scope and Date — 固定範疇和日期（不建議）#

此方法的問題：

• 同時鎖定兩個最難預先定義的變數
• 實務上，時間快用完時，範疇或日期中必有一個會讓步
• 「彈性預算」通常意味著加人，但 Brooks 法則告訴我們：「為已延遲的軟體專案加人只會讓它更延遲」
• 現實中，彈性預算往往只是讓同樣的人加班，違反可持續步調（sustainable pace） 原則

如果過度限制範疇、日期和預算，品質就會變成「彈性的」。這將導致技術債累積或交付無法滿足客戶期望的產品。

Fixed Scope — 固定範疇#

適用於範疇確實比日期更重要的情境。當時間不夠但功能未完成時，延長日期以確保 MRFs 全部交付。注意：日期延長意味著預算也必須跟著增加（人要付薪水）。

如果面臨固定範疇的壓力，通常更好的做法是考慮更小、更頻繁的固定日期發布。

Fixed Date — 固定日期（最推薦）#

許多人認為這是最符合 Scrum 原則的方式：

• 固定日期和預算，但範疇必須彈性
• 因為 Scrum 總是先做最高優先級的功能，時間到時未完成的應該是較低價值的功能
• 如果能定義出真正小的 MRFs 集合，就能輕鬆在固定日期前交付
• 固定日期也與 Scrum 的時間盒（Timeboxing） 精神一致

更新限制#

持續的 release planning 包含用當前知識重新審視限制條件。例如 SR4U 接近截止日但 MRFs 無法完成時，可能的選擇包括：

• 減少 MRFs 的範圍（例如只過濾餐廳評論、固定來源）
• 增加人手（改變預算）
• 放棄在 Social Media Expo 發布（改變日期）

Product Backlog 梳理（Grooming）#

Release planning 的基本活動之一是梳理 product backlog。Envisioning 階段的 epic 層級故事通常太大，需要在 release planning 時細化。

以 SR4U 為例，Roger 的路線圖中 Release 1.0 聚焦「基本學習」和「基本過濾」，對應兩個 epic。在 release planning 時，團隊透過 user-story-writing workshop 將其拆分為更詳細的故事，例如：

• 身為典型使用者，我希望告訴 SR4U 忽略包含特定關鍵字的評論
• 身為典型使用者，我希望選擇產品或服務類別以幫助 SR4U 聚焦

精煉最小可發布功能（Refine MRFs）#

MRFs 代表最小的「必備」功能集合。Release planning 的重要工作是持續重新評估和精煉 MRFs：

• 隨著 Sprint 回饋和已驗證學習不斷調整
• 常見問題：利害關係人無法就 MRFs 達成共識，這會干擾決策
• Product Owner 最終負責定義 MRFs，但需與利害關係人和 Scrum 團隊密切合作

為什麼要追求「最小」而非「最大」功能集合？因為最大集合花最多錢、耗最多時間、風險最高。最小集合則相反。這與更小、更頻繁發布的原則一致。MRFs 的定義應結合功能大小的估算資訊，以確認其經濟可行性。

Sprint 對應（Sprint Mapping / PBI Slotting）#

雖然每個 Sprint 要做哪些 PBI 是在 Sprint Planning 時才最終決定，但提前做一些粗略的對應是有幫助的。

做法是：使用團隊平均速率，將估算過的 PBI 分組，每組的總點數大致等於團隊的平均速率。

單一團隊#

• 在初始 release planning 時粗略了解各功能何時完成
• 可能因此重新組織 backlog，讓分組更自然或高效

多團隊#

• 使用 rolling look-ahead planning — 每個團隊不只考慮下一個 Sprint，還考慮至少兩個未來 Sprint
• 有助於管理跨團隊依賴（inter-team dependencies）

以 SR4U 三個團隊為例：

• Team 1：端到端使用者請求處理
• Team 2：AI 引擎（分析與區分評論的邏輯）
• Team 3：連接不同網路資料來源

三個團隊透過聯合 release planning 協調依賴關係，例如 Team 1 在 Sprint 2 需要 Team 3 至少完成一個資料來源的連接。

這種早期對應會隨著開發進行而演變。最終決定在每個 Sprint Planning 的「最後負責時刻（last responsible moment）」做出。有些單一團隊認為早期對應的投入不值得其產出，選擇不做或少做。

sequenceDiagram
    participant T1 as Team 1<br/>端到端使用者請求處理
    participant T2 as Team 2<br/>AI 引擎
    participant T3 as Team 3<br/>網路資料來源連接

    Note over T1,T3: Sprint 1
    T3->>T3: 開發第一個資料來源連接器
    T2->>T2: 開發核心 AI 分析演算法

    Note over T1,T3: Sprint 2
    T3-->>T1: 提供至少一個資料來源連接
    T1->>T1: 整合端到端使用者請求處理流程
    T2->>T2: 持續開發 AI 引擎功能

    Note over T1,T3: Sprint 3
    T2-->>T1: 提供 AI 引擎 API
    T1->>T1: 整合 AI 分析功能至端到端流程

Fixed-Date Release Planning（固定日期發布規劃）#

以 SR4U Release 1.0 為例，固定日期為 Social Media Expo（9 月 26 日星期一），需在 9 月 23 日（星期五）前完成。

步驟#

MRFs 比例建議#

在 fixed-date release 中，MRFs 應佔用少於 100% 的時間，建議約 60%-70%，原因有二：

1. 如果所有功能都是 must-have，時間不夠時沒有功能可以刪減
2. 如果出現緊急的 must-have 功能，有 nice-to-have 功能可以被替換掉

以範圍確定交付範圍#

將速率計算結果疊加到 product backlog 上，可以看到三個區段：

• Will Have（一定會有） — 108 點以內
• Might Have（可能會有） — 108-132 點之間
• Won’t Have（不會有） — 132 點以外

這種範圍式回答既準確又誠實地傳達了不確定性。

疊加 Must-Have 線#

將 must-have 線疊加後可得到三種情況：

flowchart TD
    A[疊加 Must-Have 線] --> B{Must-Have 線\n落在哪個區域?}
    B -->|Will-Have 區| C["Good News\n放心進行"]
    B -->|Might-Have 區| D["Maybe OK\n接受風險並持續監控"]
    B -->|Won't-Have 區| E["Bad News\n考慮不進行或調整範疇"]

每個 Sprint 結束後必須重新檢視 release plan，更新速率數據和 backlog 變化。

Fixed-Scope Release Planning（固定範疇發布規劃）#

當範疇確實比日期更重要時使用。

在開始 fixed-scope 規劃之前，先問自己：是否真正將 must-have 功能精簡到了最低限度？很多時候，積極地思考「最小可發布功能」可以將 fixed-scope 轉變為一系列更小的 fixed-date 發布。

步驟#

以 150 點的功能集合為例：

• 150 / 22（較快速率）= 7 個 Sprint
• 150 / 18（較慢速率）= 9 個 Sprint
• 回答：7 到 9 個 Sprint（14 到 18 週）

同樣是範圍式回答，誠實傳達不確定性。

成本計算（Calculating Cost）#

成本計算在 fixed-date 和 fixed-scope 發布上都很簡單：

• 軟體開發成本的大部分是人事成本，可作為整體成本的良好替代指標
• Fixed-scope 時，組織通常以較高端做預算
• 另一種方法：如果知道歷史的每點成本（cost per story point），可直接用 150 x 每點成本來估算

溝通進度（Communicating Progress）#

大多數團隊使用某種形式的 Burndown Chart 和 / 或 Burnup Chart 作為主要的資訊輻射器。

Fixed-Scope Release 的進度溝通#

Burndown Chart（燃盡圖）#

• 縱軸：剩餘未完成工作的大小（story points）
• 橫軸：Sprint
• 每個 Sprint 結束後更新，顯示剩餘工作量
• 可加入預測線（高/低/平均速率）顯示預計何時完成

Burnup Chart（燃起圖）#

• 顯示發布的總工作量作為目標線，以及每個 Sprint 向目標的進展
• 有些人偏好 burnup 格式，因為它能輕鬆顯示範疇變更

當發布的範疇增加時，只需在新增範疇的那個 Sprint 將目標線向上移動即可。

Fixed-Date Release 的進度溝通#

傳統的 burndown/burnup chart 不適用於 fixed-date planning，因為它們假設已知總範疇量。作者提出一種特殊的 burnup chart：

• 倒置 Product Backlog — 最高優先級項目放在底部，低優先級在頂部
• 這消除了需要事先知道發布範疇大小的問題
• 每個 Sprint 結束後向上燒，顯示完成的功能
• 可以同時觀察：
  • 向目標功能範圍的進展
  • 是否能完成 must-have 功能
  • will-have / might-have / won’t-have 的分界

小結#

本章擴展了 release planning 的描述，涵蓋了時機、參與者、活動內容，以及 release plan 的要素。核心內容包括：