共计 1118 个字符，预计需要花费 3 分钟才能阅读完成。
产品经理对于如何做版本迭代规划，有时总会产生无力感，要么是计划难以确定下来，要么是制定好的计划无法执行下去，这个问题的原因很复杂。在项目初期，我们缺少对产品的全局概念和整体把握，内部意见很难统一；再者，没有一个完整的用户体验或者价值流导向，对于每个迭代无法合理定制出可交付产品增量。
之前我们讲过如何构建产品路线图，路线图可以给 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 官方博客，如转载请注明出处。
原文链接：如何做产品的版本迭代规划？
