Release 截止日期通常是固定的，由外部因素（例如展會、財務壓力或合約義務）決定。但由於目標是盡快將可用的軟體交付給用戶，以便儘早進行“調整”，因此會盡一切努力縮短軟體發布週期。敏捷發布週期當然應該短於一年，通常短至六個月或三個月。而一個版本又由多次迭代組成。對於特定項目，每次迭代的長度通常固定在一周到一個月之間。如果發布週期為六個月，每次迭代持續兩週，那麼整個版本將包含 13 次迭代。
在某些環境下，軟體可能會在每次迭代結束時或每隔幾次迭代以增量方式交付給使用者（或至少部分使用者）。在確定初始功能清單、優先順序並進行初步估算後，團隊會召開發布計畫會議，以製定總體發布計畫並確定哪些功能可以交付。然後，根據優先順序排序的總體發布計劃將直接用於指導各個迭代計劃。
一些敏捷方法強調程式設計師和客戶之間職責的明確劃分。在規劃階段，只有客戶負責業務決策和優先排序，而只有程式設計師負責任務估算和開發執行。 敏捷方法 同時強烈反對管理層隨意地將技術選擇強加給開發團隊，而是給予開發人員盡可能多的自由，讓他們為系統和專案選擇最佳工具。
初步發布計劃
初始版本規劃的目標是大致估算在發布截止日期前（假設截止日期固定）將交付哪些功能，或為一組特定功能選擇一個大致的交付日期（如果範圍固定）。我們利用這些資訊來判斷專案是否能產生足夠的投資報酬率以回收成本，從而決定是否繼續推進。
初始版本發布計畫會議通常不會超過一天——如果你實在無法忍受一整天的會議，那也可以安排兩個半天。首先，客戶會提出需要交付的優先功能。理想情況下，開發人員應該已經對實現每個功能所需的工作量有了大致的估算。
團隊會根據開發人員的估算和客戶的功能優先順序制定發布計劃，大致將各項功能對應到最初的幾個迭代版本。開發人員可能會發現，一些優先順序較低的功能也存在設計或架構方面的風險，因此可能會要求客戶考慮將這些功能安排到更早的迭代版本中，以便在專案早期儘早解決這些潛在風險。
如果已知開發團隊在前一個版本中的開發速度，那將非常有幫助。在這種情況下，如果範圍固定，您可以將所有所需功能的總估算值除以團隊的開發速度，從而得出交付功能所需的大致迭代次數，進而確定截止日期。如果截止日期固定（通常情況下如此），則將開發速度乘以迭代次數，即可初步了解可以交付多少功能。如果開發團隊的開發速度未知，則他們必須提供一個估算值，並且必須理解，在得出可靠的開發速度之前，發布計劃在前幾個迭代中不會非常精確。
初步發布計劃
初始發布計畫很少能讓所有參與者都滿意——要么功能交付不足，要么交付所需功能所需時間過長。但在敏捷開發中，團隊會直面這些殘酷的現實，並圍繞這些現實制定軟體開發計畫。沒有人相信能夠讓所有人都滿意的「奇蹟」。團隊不會集體否認，而是利用真實的指標和協商，在計畫初期就做出艱難的抉擇。
敏捷思想領袖們一致認為，雖然 可能 要調整特定項目的範圍、截止日期、資源和質量，唯一能夠有效調整的變數只有截止日期和範圍。大量研究表明，規模較大的團隊往往交付品質較低、速度較慢的系統，而規模較小的團隊則傾向於交付品質較高、速度較快的系統。雖然增加程式設計師可能確實有必要，但這很可能會至少在一段時間內拖慢團隊的進度，而不是加快進度。一旦我們接受了這些結論，就意味著我們必須在發布計畫中調整範圍或截止日期，以製定一個能夠被發起人、客戶、開發人員、管理人員和其他利害關係人認可的可行發布計畫。團隊提前做出這些艱難的抉擇，可以降低專案的整體風險，並提高團隊按時交付能夠充分回報利害關係人投資的功能集的可能性。
持續規劃發布
初始發布計劃通常只是粗略的。它只需足夠詳細，足以讓我們啟動項目，並預測項目能夠帶來足夠的投資回報，從而收回成本。 （如果初始發布計劃預測的投資回報率過低，不足以證明專案的合理性，那麼我們可以在浪費大量資金之前取消專案。）在敏捷專案中，我們會持續進行計劃，並根據實際情況不斷調整方向。調整方向的主要機制之一是允許發布計劃根據各種回饋進行演進。團隊的開發速度至少需要幾次迭代才能穩定下來。迭代有時會交付比計劃少的功能，有時則交付更多。某些功能、架構選擇、設計選擇、框架或技術選擇可能被證明風險過高，或者根本行不通。使用者介面可能需要修改。人員可能會流失或增加。功能優先順序可能會發生變化。所有這些因素都將幫助我們不斷修訂和完善發布計劃。每次發布新的迭代計劃時，都應該同時發布一個反映最新情況的修訂版發布計劃。
啟動與總結
許多敏捷團隊計劃在第一次迭代（通常稱為「迭代 0」）中僅交付少量功能，以便明確地解決初始的技術和後勤問題，並可能對架構進行端到端的壓力測試。這對於缺乏敏捷經驗的團隊至關重要。對於沒有良好速度指標的團隊而言，這可能意味著只有在第二次或第三次迭代結束時，速度才能變得穩定可靠。
有些團隊還會在專案接近尾聲時安排最多兩次迭代，用於系統穩定性、全系統整合和測試、缺陷修復以及使用者文件完善。理想的敏捷專案並不需要這樣做，但在實際應用中，這取決於團隊遵循的具體敏捷實踐、組織結構、系統的整體複雜性、團隊需要交付的非程式碼成果、系統部署的複雜性以及其他類似因素。
常見問題
我真的需要使用版本發布和版本發布計劃嗎？
有些球隊可以靠其他方式生存下去 敏捷規劃 在發布層級。例如，ASP 可能只是在每次迭代（即每隔幾週）中將軟體交付到生產環境，因此每次迭代實際上都是一次發布，簡單的迭代敏捷計劃就足夠了。另一方面，如果管理階層需要在軟體層面上獲得一定程度的可見性，則需要進行更細緻的管理。 發布管理 如果軟體開發進度達到一定水準（例如，進度、狀態、與初始軟體開發計畫的變更等），那麼發布層級的規劃和管理就顯得尤為重要。
發布規模有多大？
Release發行週期通常為兩到十二個月。對於較長的發行版本，將其拆分為幾個子版本可能更合理。
一個版本包含多少次迭代？
版本迭代次數通常取決於進度安排。如果一個版本週期為六個月，每次迭代持續兩週，那麼該版本應該安排 13 次迭代。
誰參與版本發布計畫？
對於規模較小的團隊，讓整個跨職能團隊參與，既能提供意見又能確保責任落實，可能更合理。而對於規模較大的團隊和組織，則可以選擇或選出部分團隊成員代表團隊參與。
發布計劃會議通常持續多久？
Release 計劃會議通常持續四到八個小時。
為召開版本發布計畫會議，需要做多少準備工作？
通常情況下，在發布計劃會議之前，專案審批、預算、願景、團隊組建等方面已經做了很多工作。就功能而言，客戶可能已經花時間與開發團隊合作，確定初始功能，並可能將其分解並提供初步的、高層次的估算。
發布計劃在發布過程中會改變嗎？
隨著更多資訊的揭露、功能的實現、系統理解的加深、業務需求的演變以及優先順序的調整，版本發布的整體組成幾乎肯定會改變。儘管這種變化是可以預見的，但軟體發布管理的演變仍需與所有相關利益方進行溝通。
