在 Scrum 敏捷模型中，敏捷的落地，其实主要是通过 Scrum 定义的四个主要仪式，也就是我们通常说的 敏捷四会 来完成的，本文我们探讨四会中 Sprint Planning 会议的作用以及其实践要点。

Planning会议的作用

在每一个Sprint的开始，首先就会召开这个Sprint Planning会议，同时这个会议也标志着Sprint开始。

这个会议的主要作用，当然如其名，就是制定当前Sprint运作的计划，确定团队在当前Sprint的工作内容和工作方向，形成Sprint的待办列表 SBI。

会议的输入

PBI

Planning会议最主要的输入，是产品待办清单 PBI。

会议中的主要讨论其实主要是围绕 PBI 展开的，也就是要从 PBI 中提取经过团队共同确认的待办项，纳入当前迭代，形成 SBI

而作为会议输入的 PBI，应该是已经和团队一起经过梳理、提炼的需求。团队成员对需求本身也有了充分的理解，并完成对待办项工作量的估算。所有待办项也都有优先级的定义。

这也是在召开Planning会议前，PBI最好是已经经过grooming会议做过了需求澄清和估算的主要原因。以提高planning会议的效率。 当然在Planning会议上，也会存在对需求的进一步澄清和确认过程，只是为了控制时间，这部分可以尽可能提前打好充分基础。

DOR/DOD

另外一个重要的输入是团队集体对DOR和DOD的定义，这个通常在sprint 0上确认。后续Sprint可以沿用，如果有修正再重新确认。

关于DOR 和 DOD，我们介绍Sprint工件的时候有过说明，不再赘述。

DOR 其实是可以进入Sprint的待处理需求的标准，符合DOR的需求才应该进入 Planning的讨论。 DOD 则是Sprint进行中，每个待办项可以认为完成的标准。

Planning会议上应该确认大家对此有共识。

Capacity（产能）

这个体现的是团队的生产能力。每个 Sprint 团队成员的产能是不固定的，因为可能有成员休假，借调或者本来就不是全职投入的情况。因此在召开 Planning 会议前， Scrum Master应该提前收集掌握好当前Sprint团队整体的Capacity。

会议要解决的问题

在Planning会议上其实主要就是要解决三个问题： Why？ What？ How？

• Why？

为什么我们要进行这个sprint？ 团队要理解这个sprint中的工作带给产品的价值是什么。 PO需要向大家说明他希望达成的价值目标，要能够回答团队为什么我们要做这些需求？为什么这些需求应该要放到当前这个sprint？

• What？ Sprint中具体要做的是什么？如果需求已经经过了grooming的梳理和提炼，这里就会节省很多时间。但如果需求还没有充分澄清，或者会议中产生了新的一些思路，PO和团队这里要完成对需求细节的梳理，识别相关的风险和依赖，并达成理解一致。

• How？ 这部分更多是开发团队成员的讨论内容，就是确定具体如何纳入Sprint的需求实现？并将需求Story再拆分成不同的工作任务，匹配到人，Scrum Master会和团队一起，完成任务的分配和团队Capacity的平衡。

会议的输出

Planning会议最主要的输出，当然就是SBI，包含当前迭代中需要完成的所有任务项。

此外，还有一个我们之前介绍过的工件，Sprint Goal。 这个阐明了团队和PO共同达成的迭代应该要力争完成的目标摘要。

会议时长

敏捷组织的经验数据是根据sprint的长度，每周对应2小时，也就是如果sprint是1周的话，sprint计划会大概要开2h，而通常sprint一般是2周的长度，这时sprint计划会则需要4个小时。

当然这只是经验数据，不同团队根据团队规模、成熟度和工作的复杂程度会有所不同。

不同角色应如何参与

Planning会议主要是团队内部会议，参与人包括团队全体成员。极少数的情况下，会邀请主要的利益干系人（直接老板）。在需要他们给出一些决策输入时，可能需要邀请参加。对于比较大的项目，存在多个Scrum团队合作的情况，可能也会邀请到其他团队的关键工程师，来参与一些重要的技术评估。但总体来说，这个会主要还是团队内部的讨论为主，参与人是PO、SM和Dev Team。

PO

PO在计划会前，要完成PBI的优先级排列，并和团队提前完成需求的grooming。

在会议进行中，则主要是要解答Why和What的问题，并提出期望的sprint goal，确认Scope。

会议最后，要团队一起确认会议输出：sprint Goal和SBI。

SM

Scrum Master在会前要预定会议，收集团队的投入产能，有那些人需要休假，每位成员在Sprint中的投入时间。

会议中，SM负责主持，要组织会议流程，协助团队进行任务的分解和工作分配，确保scope中的所有任务都有对应的owner负责人。

在任务分配和认领过程中，要随时检查团队成员的任务和个人可投入时间的匹配情况，避免出现过度认领。还包括在一些互相依赖任务上进行协调的工作。

最后，SM要负责汇总出SBI，并和团队一起确认goal。一般还会有一个收集大家对完成Sprint goal的信息指数环节。

在会后，SM还一应该准备好sprint看板，把相关任务设置到初始状态，并发出会议纪要。

Dev Team

会前，团队成员应该将个人在当前迭代的投入时间告知SM，提前参与PO的grooming，充分了解PBI中的相关需求细节。

在会议召开过程中，确保自己理解了sprint的目标，另外如果有需求需要进一步说明，积极参与梳理，理解需求，完成估算，主动提出并讨论识别到的风险、依赖。 然后和团队一起，根据自己迭代中的Capacity认领任务，承诺产出）。

最后大家一起确认sprint goal，给出自己对sprint完成goal的信心指数。完成sprint的启动

会议流程

再总体梳理下会议进行的流程

SM 召集会议后，

1. PO首先说明期望的sprint目标和当前Sprint的工作范围。并给出相关的理由，对产品的价值说明。团队一起就这部分完成讨论，初步确定scope和goal

2. 接下来针对Scope中的需求逐一进行澄清，对照DOR，如果没有进行过groom的需求，这时完成梳理澄清和工作量估算。同时识别可能的风险和依赖，并讨论应对措施。

这两个阶段是Planning会议的上半场，也是PO的主场

3. 接下来的下半场是开发团队的主场，针对已经理解的需求，再进行任务的拆分，具体分配到人。SM根据任务认领情况，要同步观察Capacity的匹配情况，确保没有遗漏任务和过度认领。这个环节视情况，PO不是必须参加。即使参加，也主要是回答一些讨论中出现的对需求的疑问。

4. 最后，所有团队成员共同确认达成一致的sprint goal，输出SBI。也代表团队对目标和范围的承诺。最后，团队全体可以对成功完成sprint给i出一个信心指数（0~5）。

会议全程，SM负责主持，应该控制会议节奏，注意进度和时间。

总结

通过上面的说明，大家应该可以看到，sprint planning会议是敏捷运作中非常关键的一个会议：

• 通过计划会，产生了一个明确的sprint目标

• 团队正式开始Sprint前，通过计划会完成了充分沟通，整体工作范围、目标对所有成员透明化，增进了理解

• 尽可能准确地匹配了团队的产能和纳入迭代中的工作任务

• 每项待办需求经过拆分和认领，都有了明确的负责人

• 团队集体完成了SBI和目标，加强了互相之间的合作。也为完成迭代奠定了信心

关注秋草的公众号，及时了解更新动态