成功推进Scrum需要一些重要的会议，包括Sprint计划、Sprint审查、每日Scrum和Sprint回顾等。

作为一个敏捷教练，我在辅导很多Scrum团队的时候发现，很多人对关于谁应该参加这些会议、什么时候举行这些会议、每个会议需要多长时间、会议的目的等等有很多困惑，后来我就做了一个Scrum迭代日历发给了他们，他们顿时觉得清晰多了（微信搜索“小船哥说敏捷”，回复“迭代日历”可以直接下载Excel版）：

Scrum迭代日历

下面我来就这个日历做一些解读：

0.写在前面

我在辅导团队的时候经常会遇到的一个反馈是：Scrum的会议太多了，我们能不能少开一些？

遇到这个问题的时候，我一般的回答是：

会议只是形式，敏捷不强求一定要开会，只要能达到每种会议背后的目的即可。

那如果我们不开会，怎样来达到这些目的呢？对于我们经常说的这些会议（Meeting），Jeff在Scrum指南中称作事件（Event），Mike Cohn将其称作仪式（Ceremony），我个人比较偏向于仪式（Ceremony）这个词。

仪式的简单解释是“从一种状态向另一种状态转化的过渡阶段、中间状态”，比如结婚的仪式，就是情侣向夫妻转化的中间阶段。但是仪式只是一个抽象的概念，我们要怎样实现仪式呢？还拿结婚举例，常见的仪式就是婚礼，除了婚礼之外，现在也有很多的年轻人通过旅行结婚、集体婚礼的方式来完成这个仪式。

所以要实现敏捷的各种仪式，我们“常见”的方式就是会议（Meeting）（类比结婚这个仪式的常见实现形式是婚礼），除了会议以外，我们也可以采用其他一些方式来实现，下文中会给出一些建议。

那我们可以放弃或裁减掉一些仪式吗？我之前看过一篇心理学的调研（暂时找不到在哪了，后续找到的话我会把链接贴出来），心理学家采集了结婚7年后的夫妻的很多关于幸福度的指标，调研结果显示：那些办了婚礼的夫妻，比那些未办婚礼的夫妻，幸福度要高很多。所以，这些敏捷的仪式要不要裁剪，你们自己看着办吧~ :)

1.需求梳理

需求梳理是指确保产品待办列表顶部的需求已准备好排入下一个迭代。这包括为需求增添细节、估算和排序等。需求梳理的目的是使需求更适合排入Sprint。

虽然需求梳理这个过程是必须的，但并不强制要求团队将其作为一个正式的会议。但是大多数团队会定期召开需求梳理会，通常每迭代一次或每周一次。

需求梳理的一般原则是，无论在会议中，还是在可能由这些会议引发的讨论中，花费在改进产品待办列表的时间不应超过团队总可用时间的10％。

Scrum指南建议让Scrum团队来决定如何以及何时完成需求梳理的工作。大多数团队是让整个开发团队、PO和SM一起参与。但是《用户故事实战》一书建议，除非团队要在梳理会上对用户故事进行估算，否则只要开发团队的一半到三分之二的人就足够了；《用户故事地图》一书建议，由业务、研发和测试这三个角色组成的3-5人的跨职能小组参加即可。后面的2种组织方式，可以减轻团队的总体会议时间负担。

这个流程的输入是Product Backlog。输出是梳理后的Product Backlog，Backlog中的需求项通常被分割成更小的、更适合排入Sprint的用户故事，以及对某些需求的更深刻的理解。

2.Sprint计划

Sprint计划标志着迭代的正式开始。一旦这个会议开始，迭代也就开始了。

整个开发团队、PO和SM都将参与这个会议。Sprint计划会的长度与迭代的长度成正比。按照Scrum指南的建议，一个月的迭代，计划会议最好不超过8个小时，如果是两周的迭代，会议时长最好不超过4小时。

这个时间是最大的时间盒，我建议团队可以通过不断的迭代，将时间控制在最大时间盒的一半左右，即两周的迭代能控制在2小时左右。

这个流程的输入是团队的平均速率（我一般建议是过去3个迭代的数据做平均）、最新速率、Product Backlog，前两个数据由SM提供，后一个的数据由PO提供。在许多团队中，PO还会提供一个Sprint目标的草案，该目标草案可以在计划的过程中，与开发团队一起协商、修改。

Sprint计划的输出是Sprint Backlog，以及一个大家都认同的Sprint目标，还有一个隐性的输出是一个对即将到来的工作更加了解并为之做好了充分准备的团队。

3.每日Scrum

每日Scrum（Daily Scrum），也称为每日站会（Daily Stand-up），是一个简短的、团队成员同步工作、寻求协作的每日会议。每日Scrum使团队成员能够确保正确的人在正确的时间处理正确的事情。

Scrum指南中对每日Scrum的召开方式给了一个“可以使用的范例”：

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

除了这种范例以外，也可以使用其他的方式来进行，例如，很多团队发现相比于描述自己“做了什么”，他们认为描述“完成了什么”更有利于目标的实现。

每日Scrum的参与者包括整个开发团队、PO和SM。关于PO是否应该参加每日Scrum，在一些Scrum的微信群、论坛上存在不少争议，我个人认为如果将PO从每日Scrum中排除出去，会使PO和开发团队造成隔阂。Scrum强调的是跨职能组织，要推倒部门墙，我们既然都是一个团队了，为什么要把PO排除在外呢？

每日Scrum的时间限制为15分钟，其目的是为了进行简短的更新和同步。与Sprint计划不同，我建议每日Scrum的时间不要太短，对于大多数团队而言，5-7分钟的会议时间根本不足以提出任何实质的问题或理解正在完成的工作。当团队将每日Scrum的时间缩短得太多时，会议就会变成一系列机械的更新，比如“昨天我做了这样那样的事，今天我要做这个和那个，没有什么问题阻碍我。”

每日Scrum没有正式的输入，唯一的输出是增加了开发团队的工作协调性。

4.Sprint评审

Sprint评审在迭代的最后一天进行。整个开发团队、PO、SM和任何相关的利益相关者都应参加。利益相关者可能会根据迭代交付内容的不同而有所变化。

按照Scrum指南的建议，一个月的迭代，Sprint评审的时间最多为4个小时。评审的时间会随着迭代长短按比例缩放，对于两周的迭代，则应缩短到2小时。

这个流程的输入是，所有符合完成定义（DoD）的用户故事，这意味着团队不会演示仍在进行中的工作。

在Atlassian公司（旗下的产品有Jira、Confluence、Trello等），他们的一些团队会采用非会议的方式进行Sprint评审，比如他们会聚集在团队成员的办公桌旁看他们演示新功能。在办公室里大家经常会听到鼓掌的情况。

Sprint评审的主要流程是完成功能的演示，但大多数团队也会花时间来讨论进展和问题，以便从利益相关者那里获得更多关于构建结果和未来产品方向的反馈。PO会考虑所有反馈，并更改Product Backlog。因此，迭代评审的输出是一份修订后的Product Backlog。

5.Sprint回顾

Sprint回顾是团队成员考虑如何改进工作方式的时间，在这个会议上大家可以讨论Scrum的流程、合作的方式，遇到的障碍、改进的办法等等。整个开发团队、PO和SM都应该参加Sprint回顾。

Sprint回顾的输入是团队的客观数据，我一般会带来团队过去5个迭代的故事数、故事点数、故事流动时间等数据的趋势图，以及本次迭代的燃尽图，以此引发大家对团队产出、合作流程的思考和讨论。输出是团队对其工作方式的改进项。

按照Scrum指南的建议，一个月的迭代，Sprint回顾会的时间限制为3小时。对于较短的Sprint来说，会议时间通常会缩短。但是这个缩短的时间跟Sprint计划和Sprint评审不一样，它没法做到会议时间随迭代长短按比例缩放，但是我们要尽可能的缩短这个会议的时间。

6.小结

Scrum创始人Jeff在《敏捷革命》一书提到，敏捷实践要遵循“守破离”的节奏：先遵守规则，再打破规则，最后成为规则。所以对于这份Scrum迭代日历，我建议大家先尝试以“会议”的形式，在熟练掌握各个会议的流程及其背后的意义之后，再尝试做一些规则的突破。

至于最后能不能成为新的规则，不努力一下怎么会知道呢？

全文完，微信搜索“小船哥说敏捷”，回复“迭代日历”可以直接下载Excel版。