Scrum 包含哪些事件？

Scrum 用一组固定的事件来代替零散随意的会议，让团队以稳定的节奏向前推进。所有事件都是时间盒（Timebox）事件，也就是每个事件都设定了明确的时长上限：一个事件只要达成了目标就可以提前结束，但不得超过上限，以此确保时间被有效利用，减少过程中的浪费。

Sprint 除了本身是一个事件，同时也是其他所有事件的容器。Scrum 中的每个事件，都是一次正式的检视与适应机会——它们被专门设计出来，用来确保透明和信息可见。如果 Sprint 无法包含其中的任何一个事件，透明程度就会下降，团队也就失去了检视与适应的机会。

一、Scrum 的五个事件总览

把五个事件放在一起看，可以快速看清各自的时间盒与用途：

二、Sprint：其他事件的容器

Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的固定时限。在这段时间里，团队构建一个「完成」的、可用的、潜在可发布的产品增量。在整个开发过程中，Sprint 的长度保持一致，前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

每个 Sprint 都可以看作一个为期不超过一个月的项目：它有一个要构建什么的目标，也有一份灵活的计划用来指导怎么做。当 Sprint 拉得过长时，对「要构建什么」的定义可能发生偏移，复杂性和风险都会随之上升。把长度限制在一个月内，能让团队每月至少检视和适应一次进度，从而实现可预测性，也把风险限制在一个月的成本上。

在 Sprint 期间，有三条原则需要遵守：

• 不能做出有害于 Sprint 目标的改变；
• 不能降低质量目标；
• 随着信息增加，产品负责人与开发团队之间可以对范围重新澄清和协商。

取消 Sprint 的规则

Sprint 可以在时间盒结束之前被取消，但只有产品负责人才拥有取消 Sprint 的权力。当 Sprint 目标已经过时——例如公司方向、市场或技术状况发生改变——Sprint 就可能被取消；总的来说，如果一个 Sprint 对所在环境失去了价值和意义，它就应当被取消。

取消 Sprint 时，任何已经「完成」的产品待办列表项都需要评审；具有潜在可发布价值的部分，产品负责人通常会接受。所有未完成的条目会被放回产品待办列表并重新估算。需要注意的是，取消 Sprint 会消耗资源，团队成员需要重新集合到另一次 Sprint 计划会议中开始新的 Sprint，因此实践中取消 Sprint 非常罕见。

三、Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中规划，这份计划由整个 Scrum 团队共同协作完成。计划会议同样是有时间盒的：以一个月长的 Sprint 来说，上限为 8 小时；Sprint 越短，会议时间通常越短。Scrum Master 要确保会议顺利举行，让每位参会者理解会议目的，并引导团队遵守时间盒规则。

计划会议需要回答两个问题：接下来的 Sprint 交付增量中要包含什么内容？以及如何完成交付增量所需的工作？

话题一：这次 Sprint 能做什么？

开发团队预测本次 Sprint 要完成的功能；产品负责人讲解 Sprint 目标以及达成目标所需的产品待办列表项。会议的输入包括产品待办列表、蕞新的产品增量、开发团队的能力预测以及以往表现。只有开发团队可以评估接下来的 Sprint 能完成多少工作。

话题二：如何完成所选的工作？

在选定产品待办列表项之后，开发团队决定如何把这些功能构建成「完成」的产品增量。所选条目加上交付它们的计划，就构成了 Sprint 待办列表。团队以自组织的方式领取任务，领取可以在计划会议中和 Sprint 期间按需进行。如果团队认为工作过多或过少，可以与产品负责人重新协商范围。

Sprint 目标的角色

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的，在计划会议中确定。它为开发团队提供指引，让团队清楚为什么要构建这个增量，同时为实现的功能留出一定弹性。团队在工作中需要时刻谨记 Sprint 目标；如果实际所需工作与预期不同，需与产品负责人沟通协商范围。

四、每日 Scrum 站会

每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件，在 Sprint 的每一天都举行。站会在同一时间、同一地点进行，以降低复杂度。它的作用是检视达成 Sprint 目标的进度，并检视完成 Sprint 待办列表的进度趋势，同时为接下来的 24 小时制定计划。

会议结构由开发团队自行设定，常见的三个引导问题为：

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

站会结束后，团队成员常常会立即聚在一起做更详细的讨论，或对剩余工作进行调整和重新计划。Scrum Master 负责确保站会如期举行并控制在 15 分钟内，但会议由开发团队自己主持。这是开发团队的内部会议，如果有团队之外的人出席，Scrum Master 需要确保他们不干扰会议进行。

五、Sprint 评审会议

Sprint 评审会议在 Sprint 快结束时举行，用来检视所交付的产品增量，并按需调整产品待办列表。Scrum 团队与利益攸关者共同讨论本次 Sprint 完成的工作，并基于完成情况和产品待办列表的变化，讨论接下来做什么能优化价值。这是一个非正式会议，不是进度汇报会；演示增量的目的是获取反馈、促进合作。

时间盒方面，一个月长的 Sprint 对应的评审会议上限为 4 小时，较短的 Sprint 通常相应缩短。会议通常包含：产品负责人邀请 Scrum 团队与主要利益攸关者参加；说明哪些产品待办列表项已「完成」、哪些没有；开发团队讨论过程中做得好的地方、遇到的问题及解决方式，并演示已完成的工作、解答关于增量的疑问；产品负责人介绍当前产品待办列表情况，必要时预测可能的目标交付日期；参会者共同探讨下一步工作，为下一个 Sprint 计划会议提供输入。

评审会议的结果是一份修订后的产品待办列表，其中阐明了很可能进入下一个 Sprint 的条目；产品待办列表也可能为迎接新机会而做整体调整。

六、Sprint 回顾会议

Sprint 回顾会议是 Scrum 团队检视自身、并创建下一个 Sprint 改进计划的机会。它发生在 Sprint 评审会议之后、下一个 Sprint 计划会议之前。对于一个月长的 Sprint，回顾会议的时间上限为 3 小时，较短的 Sprint 相应缩短。

回顾会议的目的有三个：检视前一个 Sprint 中关于人、关系、过程和工具的情况；找出并排序做得好的方面和潜在需要改进的主要方面；制定改进团队工作方式的计划。Scrum Master 作为团队的一员参加，并确保会议保持积极、富有成效。

在回顾会议结束时，团队应明确接下来要实施的改进，并在下一个 Sprint 中落实。虽然改进可以在任何时候执行，但回顾会议提供了一个专注于检视与适应的正式机会。

七、关于 Scrum 事件的常见问题