發布計劃的目的是概述各種功能或產品何時將交付給客戶,使團隊能夠溝通產品開發的路線圖和交付時間表。Scrum團隊能夠溝通產品開發的路線圖和交付時間表。透過長期規劃,團隊可以滿足產品負責人和專案利益相關者的期望,並幫助回答關鍵問題,例如:產品負責人和專案利益相關者,並幫助回答關鍵問題,例如:
- 我們何時才能完成?
- 到年底我能夠擁有哪些功能?
- 這會花費多少?
- 識別關鍵日期和里程碑
- 協調依賴系統的開發時間表
- 協助在範圍、時間表和預算的限制內平衡商業價值與整體品質
發布規劃模式
許多組織都有自己向客戶發布產品的節奏。有些選擇在每個Sprint之後發布。其他則將多個Sprint的成果整合成單一版本,如下圖所示。還有一些在每個功能完成後立即發布——這種方法通常被稱為持續部署或持續交付。

就緒定義
發布計劃是一份路線圖,反映對哪些功能將被實現以及何時完成的期望。根據開發策略,它可以是功能驅動的——目標是在預定的一組功能開發完成後交付發布版本——或日期驅動的,即在預定的檢查點進行發布。如果專案是功能驅動的,發布中所有功能的總和可以除以預期的速度以估算完成所要求功能所需的Sprint數量。
你真的需要一個發布前計劃嗎?
發布規劃在敏捷中是一個有爭議的話題。雖然在商業世界中我們經常被要求提供成本和時間表的預測,但Scrum並不建議制定僵化的預先定義發布計劃。以下是反對事前發布規劃的一些論點:
- 客戶通常認為發布計劃毫無價值,並將其視為浪費
- 許多領域的快速變動驗證了「你不會需要它」(YAGNI)原則——意味著事前規劃發布是不必要的
- 因此,發布計劃的唯一價值可能僅僅是最初的日期和預算——僅此而已
那麼,我們為什麼仍然需要發布規劃?
然而,在敏捷環境中,現實的交付日期經常未能達成承諾的目標。不過,擁有大致的發布路線圖可以建立團隊與利益相關者之間的信任,並設定期望。此外,發布還應考慮所有必須完成的額外工作,例如更新公開網站和培訓客戶支援團隊。以下是進行Scrum發布規劃的主要原因:
- 溝通
- 規劃工具
- 驗證價值與成本
- 設定整體背景
發行規劃範例:
發行計畫有許多格式。以下是一個以功能/資料為導向規劃的範例:

發行規劃範例
如果專案是以日期為導向,我們只需將速度乘以迭代次數,即可確定在指定時間內可完成的總工作量。

以速度為導向的發行規劃
發行計畫並非一成不變的文件——在管理我們的產品待辦事項清單。當出現新的洞察時(例如,Scrum 產品待辦事項清單中的項目被更新或調整),發行計畫應予以審查並相應修正。