原创：【Scrum实战】二、迭代计划会

Posted 2023-05-09

参考技术A 迭代计划（ Sprint Planning ）是 The Scrum Guide 中5个迭代事件（ Sprint Events ）中的一个，这个事件是一个Sprint周期的第一个会议，迭代计划会的好坏，直接关系着后续迭代的顺利进行。

The Scrum Guide 的建议是1个月的迭代，计划会最好不超过8小时，我们公司的迭代一般都在2周，所以理论上不应该超过4小时。
但是连续开4小时的会议，几乎所有的同事都是无法保持全神贯注的注意力的，会议开到后面，很多同事就开始昏昏欲睡，或者玩起手机了。

我们公司的做法是，将迭代计划会拆成了2个会议： 迭代梳理会 、 迭代计划会 ，这两个会议分别用来讨论 The Scrum Guide 提到的两个问题：

下面分别介绍这两个会议的细节。

这个会议主要是回答 这次Sprint能做什么？ 的问题。
会议的召开时间，我们公司一般是定在这个迭代结束前的倒数第二天（结束前的最后一天是用来召开迭代评审和迭代回顾的）。

在开这个会议前，PO需要准备好以下资料：

下面分别就这几个资料做个说明：

下一迭代的梳理会前，PO需要根据之前迭代Team完成故事数的情况，从Product Backlog中预先准备好足够的Sprint Backlog，比如：之前的几个迭代，Team完成故事数基本保持在10-13个，那么PO在这次的梳理会前，他最好能准备15个以上的用户故事，这么做是因为敏捷团队是在不断成长的，它的 速率（Velocity） / 容量（Capacity） 是在不断扩容的。

优先级的确认其实应该分2步：

很多团队一直重点关注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一致，如果梳理会上有其他同事提出修改的意见（比如研发的同事会觉得有一些依赖的先后顺序、或者有一些相似的功能想要放到一块等等），可以在会上直接调整。

在梳理会上，按照DoR（Definition of Ready）的要求，最好能有高保真设计图，如果实在给不出来（这个会议是在下一迭代开始前的2天召开的，有时设计的同学确实赶不出来），低保真原型图一定是要有的，否则大家开了半天会，但是都不知道产品要做成什么样，那这个会基本等于白开了。

每一条排入迭代的用户故事，都要有详尽的验收标准，之后的开发以及测试，都是按照这份标准来进行的。

迭代梳理会由 SM引导 ， PO主持 ，时间一般控制在2小时左右（2周的迭代），会议的目的主要有：

这个会议主要是回答 如何完成所选的工作？ 的问题。
我们公司一般是安排在迭代的第一天上午进行，时间一般控制在2小时左右（2周的迭代）。

会议的主要流程如下：

迭代计划会前或者当天，高保真的设计图就必须要准备好了.
另外，迭代计划会开完以后，测试的同学就要着手开始写新迭代的测试用例了，在计划会的当天，应该就能有一份测试用例的初稿了，在迭代的第二天再开个测试用例评审会，就可以开始开发了。当然，有些经验比较丰富的测试人员，或者比较成熟的团队，测试用例写的比较好的话，也可以不用为了用例评审单独开一个会，团队成员自行看下觉得没问题就好。

上述就是我们公司迭代计划会的一些方法，每个公司的做法可能不一样，不管形式是怎样的，只要大家能回答 The Scrum Guide 中关于迭代计划会的两个问题即可。

如果大家有更好的组织形式，欢迎留言讨论。

Scrum迭代计划会

 Scrum迭代计划会怎么开

Scrum迭代计划会是Scrum最重要的会议，标志着迭代的开始，以及团队对用户故事的承诺。

在Sprint第一天上午召开Sprint planning meeting，这个会议分为两部分，计划会议上部分由PO、SM和Team参加，主要是PO从产品backlog中挑选出需要放到当前Sprint冲刺的产品Backlog即Sprint backlog item，讲解用户故事；会议下半部分由SM组织Team将SBI拆分成任务进行估算，PO也可以一起参加了解具体的开发细节以及随时解答团队对用户故事的理解。

计划会前准备

PO根据迭代计划会前的Product backlog refinement会议输出一个符合DOR的Sprint用户故事，DoR：Definition of Ready 的缩写，字面翻译“就绪定义”。目前本人参与的项目，团队达成一致，迭代用户故事DOR包括：1.用户故事介绍包括业务逻辑、验收标准；2.有优先级；3.有第三方依赖实现依赖功能时间明确；4.原型图完整。PO在梳理迭代SBI只有符合DOR才会被团队接受。用户故事的描述最好可以结构化，便于Scrum团队在迭代中协同。

SM需要在计划会前发出计划会公告，包括参会人、时间、地点、会议议程等。

计划会

计划会会议流程：

• 回顾上个迭代是否有遗留未完成的用户故事，PO决定是否放在本次迭代冲刺内

• PO讲解本次迭代目标，逐个讲解用户故事需求

• 开发人员理解需求并提问，PO回答问题，理解清楚后开发团队分解子任务并对子任务做估时或者故事点估算

• SM 记录子任务分解情况和估时情况。

如果前一个Sprint关闭迭代看板时候，会有个别上个迭代优先级低的用户故事团队未承诺完成的，PO首先要分析这些用户故事在本次迭代中优先级以及业务价值，决定是否放在本次迭代中优先冲刺还是先放在backlog中后续在完成。

PO讲解目标以及用户故事，团队达成共识后开始拆解子任务并对子任务预估时或者故事点估算，SM记录大家估算结果，分析估算情况与团队速率是否匹配。

计划会后

SM协助团队创建信息辐射器，把本次迭代冲刺的用户故事以及子任务录入到电子看板或者物理看板，同时发出本次迭代的冲刺目标、本次冲刺预估工作量和完成情况预测、潜在风险分析、本次迭代改进措施（源于上个迭代回顾会）。

迭代开始后，SM协助团队处理迭代中的障碍，组织站会，监控进度与风险。

— THE END —

写文章的坚持，更需要您的一个肯定

欢迎关注PM日常