Scrum事件是Scrum框架规定的固定活动，用来建立规律节奏、控制风险并推动检视与调整。Scrum指南定义了五个事件：Sprint、Sprint规划、每日Scrum、Sprint评审和Sprint回顾。Sprint是承载其余四个事件的容器，四个事件在Sprint内按固定目的和时间盒发生。事件属于框架规则，具体怎么开、留下什么记录，由团队在实践中决定。
要点总览（TL;DR）
- Scrum事件是Scrum指南规定的固定活动，共五个：Sprint、Sprint规划、每日Scrum、Sprint评审、Sprint回顾。
- Sprint本身是事件，同时是其余四个事件发生的时间容器，四个事件在Sprint内按固定目的和时间盒展开。
- 判断一个活动是否算Scrum事件，看三点：是否由Scrum指南规定、是否有固定目的、是否设有时间盒，团队自加的会议属于团队实践。
- 事件通过时间盒控制讨论范围，通过检视与调整推动待办、决策和改进项落地，缺少任一事件都会让检视链条出现缺口。
- 事件是活动，工件是信息载体，角色是承担职责的人，三者不能混用；每日Scrum不是汇报会，评审不是验收会，回顾不是追责会。
Scrum事件包括哪五个
Scrum的五个事件按发生顺序排列为：Sprint、Sprint规划、每日Scrum、Sprint评审、Sprint回顾。理解这个清单的关键在于分清层级：Sprint本身是一个事件，同时又是其余四个事件的容器。Sprint规划发生在Sprint开始时，每日Scrum在每个工作日发生，Sprint评审和Sprint回顾发生在Sprint结束前。
五个事件各自的一句话定义如下：
| 事件 | 一句话定义 | 在周期中的位置 |
|---|---|---|
| Sprint | 固定长度的时间盒，团队在其中完成工作并交付可用的增量。 | 贯穿整个周期，容纳其余四个事件 |
| Sprint规划 | 团队确定本Sprint要完成什么、如何完成，形成Sprint目标与Sprint Backlog。 | Sprint开始时 |
| 每日Scrum | 开发者每天用短会检视朝Sprint目标的进展，并调整当天的工作计划。 | 每个工作日 |
| Sprint评审 | 团队向利益相关者展示增量成果，检视结果并收集反馈，调整Product Backlog。 | Sprint结束前 |
| Sprint回顾 | 团队检视自身的协作方式与流程，识别改进项并决定后续如何落实。 | Sprint评审之后、Sprint结束前 |
这五个事件构成一个完整的循环：规划确定方向，每日Scrum维持节奏，评审检视产品结果，回顾检视工作方式，Sprint则把这一切框在固定周期内。缺少任何一个，检视与调整的链条都会出现缺口。
Scrum事件的定义与边界：哪些活动算，哪些不算
判断一个活动是否属于Scrum事件，可以看三个条件：是否由Scrum指南明确规定、是否有固定的目的、是否设有时间盒。三个条件同时满足，才是框架意义上的事件。团队自行增加的会议，即使名称相似，也属于团队实践，不构成Scrum事件。
按这个标准，几种常见情况可以这样判断：
- 每日Scrum之外的临时同步会：为处理某个阻塞问题临时召集的短会，没有固定目的和时间盒，属于团队自定的协作方式，不算事件。
- 站会的变体：团队把每日Scrum改成书面异步更新，或在同一时间盒内调整提问方式，仍可视为每日Scrum的实践形式；若在每日Scrum之外另加一场固定会议，则那场会议不是框架事件。
- 需求澄清会、技术方案评审会：这些活动服务于Sprint内的具体工作，可以发生在Sprint规划或日常协作中，但它们本身不是Scrum指南定义的事件。
边界还体现在主题分工上。Sprint规划、执行、评审、回顾各自怎么细化操作、用什么模板，属于迭代管理的范畴；Product Backlog如何梳理、排序和维护，属于需求池管理的范畴。本文只回答“什么是事件、哪些算事件”，不展开这些相邻主题的操作方法。同样，Scrum角色的完整职责也不在本文展开，S04只做概念层面的区分。
时间盒与检视调整：事件如何运转
时间盒是每个事件被限定的最长时长。它的作用是把讨论控制在可预期的范围内，防止某个议题无限延长而挤占其他活动。时间盒到点即结束，未完成的讨论转为后续行动项，而不是延长会议。时间盒的长度随Sprint长度调整，Sprint越短，各事件的时间盒通常越短。
检视与调整依托事件发生。Scrum强调透明度：工作状态、增量成果和协作方式要对参与者可见，事件提供了固定的检视时点。每日Scrum检视当天进展并调整工作计划；Sprint评审检视增量并调整Product Backlog；Sprint回顾检视工作方式并调整团队做法；Sprint规划则根据前序检视的结果确定新的目标。调整如果没有落到具体的待办、决策或改进项上，检视就停留在讨论层面。
四个事件在Sprint周期内的位置与输入输出可以这样理解：
| 事件 | 主要输入 | 主要输出 |
|---|---|---|
| Sprint规划 | Product Backlog、上一Sprint的成果与反馈、团队容量 | Sprint目标、Sprint Backlog、对如何完成的初步计划 |
| 每日Scrum | Sprint目标、当前工作状态、遇到的阻碍 | 当天的工作调整、需要排除的障碍 |
| Sprint评审 | 本Sprint完成的增量、利益相关者的关注点 | 反馈意见、Product Backlog的调整方向 |
| Sprint回顾 | 本Sprint的过程数据、协作中的问题 | 改进项及落实安排 |
这些输出需要在团队日常使用的工具中留下痕迹，否则下一次检视就缺少依据。以ONES为例，其敏捷研发管理方案覆盖需求池管理、迭代规划、迭代开发、缺陷追踪、迭代进度跟进和迭代回顾等场景：Sprint规划中，产品负责人可按优先级把需求规划到对应迭代，并与团队就需求与验收标准达成一致；每日Scrum中，团队借助敏捷看板对齐进度与风险，通过燃尽图观察效率变化；Sprint回顾中，团队可结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差，并用ONES Wiki沉淀经验。这些能力承载的是事件产生的待办、决策与改进项，事件本身的规则仍以Scrum指南为准。
Scrum事件与Sprint、工件、角色的区别
事件、Sprint、工件和角色是Scrum框架中四类不同的构成要素，容易在讨论中混用。事件是固定发生的活动；Sprint既是事件，又是容纳其他事件的周期容器；工件是团队维护和产出的信息载体；角色是承担职责的人。三者的区别可以用一张对照表说明。
| 对比对象 | 区别要点 | 常见混淆 |
|---|---|---|
| 事件与Sprint | Sprint是五个事件之一，同时是其余四个事件发生的时间容器；其他四个事件是Sprint内的节点。 | 把Sprint当成单纯的“时间段”，忽略它本身也是需要检视与调整的事件。 |
| 事件与工件 | 事件是活动，工件是信息载体。Product Backlog、Sprint Backlog和增量是工件，它们被事件检视和调整，但本身不是事件。 | 把“更新Sprint Backlog”当成一个事件，或把评审会等同于增量本身。 |
| 事件与角色 | 角色是Product Owner、Scrum Master和开发者，承担职责；事件是角色共同参与的活动，角色在事件中分工，但角色本身不是事件。 | 把“Scrum Master主持站会”理解为Scrum Master的专属事件，或把某个角色的例行沟通当成框架事件。 |
这张表也提示了一个判断方法：当有人问“这个算不算Scrum事件”时，先看它是不是活动，再看它是否有指南规定的目的和时间盒。工件和角色无论多重要，都不会因为被频繁讨论而变成事件。
一个Sprint里的事件长什么样：例子与常见误解
下面用一个两周Sprint的演示情景，把五个事件串起来。该时间线仅用于说明事件的位置关系，不代表任何真实团队的做法，实际安排需结合团队规模和工作方式调整。
- 第1天上午：Sprint规划。团队与产品负责人一起从Product Backlog中选定本Sprint的需求，确认验收标准，形成Sprint目标和Sprint Backlog，并初步拆分任务。
- 第1天至第10天每个工作日：每日Scrum。开发者在固定时间用短会同步朝Sprint目标的进展，指出阻碍，调整当天计划。看板上的任务状态随之更新。
- 第10天上午：Sprint评审。团队向利益相关者展示完成的增量，收集反馈，据此调整Product Backlog的后续排序。
- 第10天下午：Sprint回顾。团队结合本Sprint的过程数据讨论哪些做法有效、哪些需要改变，形成少量可落实的改进项，并明确负责人。
- 第10天结束：Sprint结束。新的Sprint随即开始，下一轮规划接续进行。
在这个时间线里，常见的三个误解值得单独指出：
- 把每日Scrum当成汇报会。如果每天由开发者逐一向管理者陈述进度、管理者据此分派任务，会议就变成了状态汇报，开发者之间的协作调整被压缩。纠正方向是让讨论围绕Sprint目标和当天计划展开，重点放在需要协同和需要排除的障碍上。
- 把Sprint评审当成验收会。评审的目的是检视增量并收集反馈、调整Product Backlog，如果只做通过或不通过的判定，利益相关者的意见就难以进入后续规划。纠正方向是把评审当作双向沟通的场合，提前准备可演示的增量。
- 把Sprint回顾当成追责会。回顾检视的是工作方式和流程，如果变成对个人的问责，团队成员会倾向于回避问题，改进项也就失去真实来源。纠正方向是聚焦可改变的做法和条件，把讨论结果转化为具体的改进行动。
这三个误解的共同后果是检视失真：会议照常召开，但透明度下降，调整失去依据。判断一个团队的事件是否在正常运转，可以看每次事件之后是否产生了可追踪的待办、决策或改进项，以及这些内容是否在下一个周期被真正检视。
常见问题
团队把每日Scrum改成书面异步更新，还算不算Scrum事件？
可以算。判断的关键在于这个活动是否保留了每日Scrum的固定目的和时间盒。团队在同一时间盒内用书面异步方式同步朝Sprint目标的进展、指出阻碍并调整当天计划，属于每日Scrum的实践形式。如果在每日Scrum之外另加一场固定会议，那场会议属于团队自定的协作安排，不构成框架事件。
Sprint评审和Sprint回顾都在Sprint结束前，能不能合并成一场会？
两者检视的对象不同。Sprint评审检视的是产品增量，参与者包括利益相关者，输出是反馈和Product Backlog的调整方向；Sprint回顾检视的是团队的工作方式和流程，输出是改进项及落实安排。合并会让两类讨论互相挤占时间，产品反馈难以充分收集，团队改进也容易停留在表面。如果时间紧张，可以分别压缩时间盒，保留各自的目的和输出。
时间盒到了但讨论没结束，应该延长会议还是直接结束？
按时间盒的规则，到点即结束，未完成的讨论转为后续行动项。时间盒的作用是把讨论控制在可预期范围内，防止某个议题挤占其他活动。延长会议会削弱时间盒的约束力，也会让参与者倾向于在会中展开本可会后处理的话题。更可行的做法是提前明确议题优先级，把需要深入讨论的内容记录为待办，在会后或下一个事件中处理。
事件产生的待办、决策和改进项，放在哪里才能被下一个周期检视？
这些内容需要落到团队日常使用的工具中，并能在下一次事件中被调取。以ONES为例，其敏捷研发管理方案覆盖需求池管理、迭代规划、迭代开发、缺陷追踪、迭代进度跟进和迭代回顾等场景：Sprint规划中，产品负责人可按优先级把需求规划到对应迭代，并与团队就需求与验收标准达成一致；每日Scrum中，团队借助敏捷看板对齐进度与风险，通过燃尽图观察效率变化；Sprint回顾中，团队可结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差，并用ONES Wiki沉淀经验。工具承载的是记录和追踪，事件本身的规则仍以Scrum指南为准。
团队规模很小，五个事件都要完整开吗？
五个事件是Scrum框架的组成部分，保留它们才能维持完整的检视与调整循环。规模小的团队可以缩短各事件的时间盒，简化形式，例如回顾用较短的时间聚焦一两个改进项。是否调整事件本身，取决于团队是否仍按Scrum框架运作；如果团队选择其他框架，事件清单也随之改变。具体怎么开属于实践层面，框架规则不因团队规模而取消。
