產品經理對於如何做版本迭代規劃，有時總會產生無力感，要麼是計劃難以確定下來，要麼是制定好的計劃無法執行下去，這個問題的原因很複雜。在專案初期，我們缺少對產品的全域性概念和整體把握，內部意見很難統一；再者，沒有一個完整的使用者體驗或者價值流導向，對於每個迭代無法合理定製出可交付產品增量。

  之前我們講過如何構建產品路線圖，路線圖可以給PO和團隊整體方向的指導，但更具體的內容，需要使用者故事地圖的方式，通過橫向的框架和縱向的任務，將一個產品完整的展示出來。然後，再通過故事點估算和優先順序的排序，來確定版本迭代計劃。   版本迭代其實是一個路線圖，展示了將要實施哪些功能以及何時完成這些功能的期望。通常遵照團隊自己的節奏，有的是一個Sprint 一個Release，有的將多個Sprint歸為一個Release中，如下圖所示。還有的在每個功能完成後立即釋出，這也通常被稱為持續部署或持續交付。 ​ ​ 根據產品開發的策略，它可以由功能驅動，目標是一旦開發出預期的功能模組就釋出; 或者由日期驅動，過了預定的檢查點就釋出。   具體如何做呢？我們可以分這個步驟來完成。   1. 建立使用者故事地圖 和客戶一起，釐清產品的使用者角色，並儘可能多地寫出使用者的行為，以及每個使用者行為下需要做的事情，然後按照使用者行為從左到右講故事。當大家把自己所能想到的故事地圖都放上去之後，再合併增減故事，最後會形成一個二維故事地圖。 ​ ​ 2. 構建產品釋出路線圖 整個故事地圖會包含很多故事點，但在一定時間完成所有功能是不太可能的，團隊要綜合考慮商業價值、市場現狀、實現難度等方面因素，確定接下來幾個釋出的內容，以及每個釋出預期能達成的目標。 ​ ​   3. 快速估算 使用者故事建立好後，我們可以對地圖中的所有任務進行快速估算，以便於能夠知道我們整個Release要釋出產品的所需大概工作量。不同於Sprint中對故事的估算，這裡更粗略更快速，可以用故事點或者T恤size（S, M, L , XL）來制訂我們的估算標準。   4. 制定Release計劃 前面工作完成後，我們對於整體產品和開發時間會有一個大概的估計，那麼就可以設計Release計劃了。我們可以按照我們的估算，設計一個Release需要釋出哪些特性，然後包括幾個Sprints，下圖為Release計劃示例。

​ ​

再將故事按照優先順序和價值進行排序放回到每個Sprint裡，可以利用一些迭代規劃的線上工具，如下圖把右側產品Backlog的內容，自由拖動到左側的Sprint中。 ​ ​   5. 產品釋出日曆 在計劃會議之後，最終確定詳細資訊，進行任何最後調整，然後與所有利益相關者共享產品釋出日曆。 ​ ​     本文作者：Kaya 首發於Worktile官方部落格，如轉載請註明出處。 原文連結：https://worktile.com/blog/design/how-to-release-planning
  &nbs