迭代计划（Sprint Planning）是The Scrum Guide中5个迭代事件（Sprint Events）中的一个，这个事件是一个Sprint周期的第一个会议，迭代计划会的好坏，直接关系着后续迭代的顺利进行。
The Scrum Guide的建议是1个月的迭代，计划会最好不超过8小时，我们公司的迭代一般都在2周，所以理论上不应该超过4小时。
但是连续开4小时的会议，几乎所有的同事都是无法保持全神贯注的注意力的，会议开到后面，很多同事就开始昏昏欲睡，或者玩起手机了。
我们公司的做法是，将迭代计划会拆成了2个会议：迭代梳理会、迭代计划会，这两个会议分别用来讨论The Scrum Guide提到的两个问题：
话题一：这次 Sprint 能做什么？
话题二：如何完成所选的工作？
下面分别介绍这两个会议的细节。
2.1. 迭代梳理会
这个会议主要是回答这次Sprint能做什么？的问题。
会议的召开时间，我们公司一般是定在这个迭代结束前的倒数第二天（结束前的最后一天是用来召开迭代评审和迭代回顾的）。
在开这个会议前，PO需要准备好以下资料：
- 用户故事（User Story）
- 优先级（Priority）
- 高保真设计图（HLD）/低保真原型图（Low Fidelity Prototyping）
- 验收标准（Acceptance Criteria）
下面分别就这几个资料做个说明：
2.1.1. 用户故事
下一迭代的梳理会前，PO需要根据之前迭代Team完成故事数的情况，从Product Backlog中预先准备好足够的Sprint Backlog，比如：之前的几个迭代，Team完成故事数基本保持在10-13个，那么PO在这次的梳理会前，他最好能准备15个以上的用户故事，这么做是因为敏捷团队是在不断成长的，它的速率（Velocity）/容量（Capacity）是在不断扩容的。
2.1.2. 优先级
优先级的确认其实应该分2步：
- Product Backlog
- Sprint Backlog
很多团队一直重点关注Sprint Backlog的优先级确认，却忽略或低估了Product Backlog优先级确认的重要性：我们在规划一个产品的时候，基本都是先定一个大方向（Epic），然后向下分解成大的功能模块（Feature），最后再分解成一个个的小功能（User Story）。
Product Backlog在确认优先级的时候，是站在整个产品的视角考虑的，所以这个优先级确认的有与无、好与坏，往往会给公司带来致命的伤害。
规模化敏捷框架SAFe（Scaled Agile Framework）提出了一种定量计算法来评估需求优先级的方法：WSJF（Weighted Shortest Job First：加权最短作业优先），下一个章节我会介绍。
在确认好Product Backlog以后，Sprint Backlog的优先级可以默认与Product Backlog一致，如果梳理会上有其他同事提出修改的意见（比如研发的同事会觉得有一些依赖的先后顺序、或者有一些相似的功能想要放到一块等等），可以在会上直接调整。
2.1.3. 高保真设计图/低保真原型图
在梳理会上，按照DoR（Definition of Ready）的要求，最好能有高保真设计图，如果实在给不出来（这个会议是在下一迭代开始前的2天召开的，有时设计的同学确实赶不出来），低保真原型图一定是要有的，否则大家开了半天会，但是都不知道产品要做成什么样，那这个会基本等于白开了。
2.1.4. 验收标准
每一条排入迭代的用户故事，都要有详尽的验收标准，之后的开发以及测试，都是按照这份标准来进行的。
2.1.5. 会议目的
迭代梳理会由SM引导，PO主持，时间一般控制在2小时左右（2周的迭代），会议的目的主要有：
- PO依次讲解排入迭代的用户故事（即Sprint Backlog）
- 团队成员有疑问时
随时发起讨论 - 每个故事讨论完成后，SM组织进行估点（这里我们用的是一个小程序：敏捷小屋）
- 估点如果超过了团队速率的80%，PO决定要将哪些故事放入下一迭代
2.2. 迭代计划会
这个会议主要是回答如何完成所选的工作？的问题。
我们公司一般是安排在迭代的第一天上午进行，时间一般控制在2小时左右（2周的迭代）。
会议的主要流程如下：
- 团队成员抓阄讲解用户故事（这么做的目的，是要让所有团队成员都能对我们所做的事情有个全面了解，而不是只关心自己做的部分）
- 拆分子任务
- 拆分任务以后，如果发现某些人的任务超负荷了，还会对故事做进行进一步调整（迭代梳理会的估点是保证总负载Load不超过速率Velocity，迭代计划会的拆分任务还要确保每个人的子任务不超过个人的速率）
迭代计划会前或者当天，高保真的设计图就必须要准备好了.
另外，迭代计划会开完以后，测试的同学就要着手开始写新迭代的测试用例了，在计划会的当天，应该就能有一份测试用例的初稿了，在迭代的第二天再开个测试用例评审会，就可以开始开发了。当然，有些经验比较丰富的测试人员，或者比较成熟的团队，测试用例写的比较好的话，也可以不用为了用例评审单独开一个会，团队成员自行看下觉得没问题就好。
上述就是我们公司迭代计划会的一些方法，每个公司的做法可能不一样，不管形式是怎样的，只要大家能回答The Scrum Guide中关于迭代计划会的两个问题即可。
如果大家有更好的组织形式，欢迎留言讨论。
