Scrum事件是Scrum框架中五个固定安排的正式活动：Sprint、Sprint规划、每日Scrum、Sprint评审和Sprint回顾。它们共同构成一个Sprint内的节奏，每个事件都有明确的目的、时间盒、参与者和产出，用来创造检视与调整的机会。Sprint是容纳其余四个事件的容器，其余四个事件分别服务于规划、每日同步、成果检视和过程改进。
要点总览（TL;DR）
- Scrum事件是五个固定安排的正式活动：Sprint、Sprint规划、每日Scrum、Sprint评审和Sprint回顾，每个都有明确目的、时间盒、参与者和产出。
- Sprint既是五个事件之一，也是其余四个事件的容器；四个内部事件分别解决做什么、今天怎么推进、成果对不对、协作方式要不要改。
- 判断一个活动是否属于Scrum事件，看它是否同时具备框架规定的目的、时间盒、参与者范围和可识别产出；临时碰头会、需求澄清会、单独汇报会通常不算。
- 五个事件靠输入输出衔接成闭环：规划产出Sprint目标与待办，每日Scrum控制日级偏差，评审更新待办，回顾产生改进项，时间盒保证节奏稳定。
- 常见误解是把每日Scrum开成汇报会、把评审开成演示会、把回顾开成追责会，后果是事件空转、检视与调整没有真正发生。
Scrum事件包括哪五个
Scrum的五个事件构成一个完整的循环。理解它们最直接的方式，是先记住名称和各自承担的任务，再去看它们如何首尾相接。下表按事件在一个Sprint中的典型顺序列出定义、主要目的、常见参与者和时间盒参考。
| 事件 | 一句话定义 | 主要目的 | 常见参与者 | 时间盒参考 |
|---|---|---|---|---|
| Sprint | 固定长度、围绕一个Sprint目标开展工作的迭代周期 | 以稳定的节奏交付可用的产品增量 | Scrum团队全体 | 通常1–4周，长度固定 |
| Sprint规划 | Sprint开始时确定本次Sprint做什么、怎么做的活动 | 形成Sprint目标与Sprint待办事项 | 产品负责人、开发人员、Scrum Master | 两周Sprint约2–4小时 |
| 每日Scrum | 开发人员每天固定时间进行的短会 | 检视朝Sprint目标的进展并调整当天计划 | 开发人员为主 | 15分钟 |
| Sprint评审 | Sprint结束时检视增量并收集反馈的活动 | 确认成果、更新产品待办事项 | Scrum团队与关键干系人 | 两周Sprint约1–2小时 |
| Sprint回顾 | Sprint结束后检视协作方式与过程的活动 | 识别改进项，提升下一轮工作方式 | Scrum团队 | 两周Sprint约1–1.5小时 |
Sprint与其他四个事件的关系是容器与内容的关系。Sprint规划、每日Scrum、Sprint评审和Sprint回顾都发生在Sprint内部，不能脱离Sprint单独存在；Sprint本身也是一个事件，它有固定的起止时间，并以Sprint目标作为贯穿始终的主线。四个内部事件各自解决一个特定问题：规划解决“这一轮做什么”，每日Scrum解决“今天怎么推进”，评审解决“做出来的东西对不对”，回顾解决“我们的协作方式要不要改”。
Scrum事件的范围边界：哪些活动算、哪些不算
判断一个活动是否属于Scrum事件，可以看四个要素是否同时具备：有框架规定的固定目的，有明确的时间盒，有约定的参与者范围，有可识别的产出。四个要素缺一，它就更接近团队自发的协作安排，而不是Scrum事件。
按这个标准，五类活动明确属于Scrum事件：Sprint本身、Sprint规划、每日Scrum、Sprint评审、Sprint回顾。它们的名称、目的和时间盒由Scrum框架规定，团队可以调整具体做法，但不能随意取消或替换其目的。
以下活动通常不属于Scrum事件：
- 每日Scrum之外的临时碰头会、问题排查会，即使每天固定召开，也缺少框架规定的事件目的与产出。
- 需求澄清会、技术方案评审会、设计走查会，这些是团队按需组织的专业活动，服务于具体工作内容。
- 向管理层单独汇报进度的会议，其目的与Sprint评审的干系人检视不同。
- 把Sprint规划、执行、评审、回顾的具体操作方法当成事件定义本身。这些操作层面的展开属于迭代管理主题，本文只在框架层面说明每个事件的目的与边界。
同样需要区分的是产品待办列表的维护。梳理、拆分、排序产品待办事项属于需求池管理的范畴，它贯穿Sprint前后，但不构成一个独立的Scrum事件。Sprint规划会用到已经梳理好的待办事项，评审会更新待办事项，这些是事件之间的衔接，而不是把待办维护本身算作事件。
五个事件如何串成一个Sprint的机制
五个事件通过输入与输出的衔接形成闭环，时间盒则保证这个闭环以稳定节奏运转。可以按一个Sprint的时间顺序理解这条链路。
Sprint规划的输出是Sprint目标和Sprint待办事项。Sprint目标说明这一轮要达成的整体结果，Sprint待办事项则是开发人员承诺推进的具体工作。这两项输出直接成为后续每日Scrum和Sprint评审的输入：每日Scrum围绕Sprint目标检视进展，Sprint评审则对照Sprint待办事项检查实际完成情况。
每日Scrum的检视对象是朝Sprint目标的进展，调整动作是当天的工作计划。开发人员在这个短会中同步各自推进情况，发现阻碍并重新安排当天的协作。它不产出新的需求，也不改变Sprint目标，作用是把偏差控制在一天的量级内。
Sprint评审检视的是Sprint产出的增量。参与者对照Sprint目标查看实际成果，干系人给出反馈，产品负责人据此更新产品待办事项，为下一轮Sprint规划准备输入。评审的产出不是一份演示材料，而是对“接下来做什么”的调整依据。
Sprint回顾检视的是过程本身：哪些做法有效、哪些环节出现阻碍、团队协作方式需要怎样调整。回顾产生的改进项进入下一轮的工作安排，成为团队持续改善的起点。至此，评审回答“产品往哪走”，回顾回答“团队怎么做得更好”，两者共同为下一个Sprint规划提供输入。
时间盒在这条链路中起约束作用。它为每个事件设定最长时长，迫使参与者聚焦最重要的检视与调整，避免讨论无限延伸。时间盒到点即结束，未讨论完的内容可以另行安排，但事件本身的节奏不被打破。正是这种固定节奏，让检视与调整成为可预期的常规动作，而不是偶发的补救。
Scrum事件与Sprint、会议、敏捷实践的区别
几个相邻概念容易混淆，逐一对照可以看清各自的位置。
| 对照对象 | 关系与区别 |
|---|---|
| 事件与Sprint | Sprint本身是五个事件之一，同时是其余四个事件的容器。其余事件在Sprint内部按序发生，Sprint的起止界定了它们的发生范围。 |
| 事件与普通例会 | 普通例会多以信息同步为目的，时长和产出弹性较大；Scrum事件有框架规定的目的、时间盒和可识别产出，开完应当留下明确的决定或调整。 |
| 事件与三大支柱 | 透明、检视、适应是Scrum的经验主义支柱，属于原则层面；五个事件是承载检视与适应的具体安排，原则通过事件落地。 |
| 事件与五种价值观 | 承诺、专注、开放、尊重、勇气是团队行为准则；事件提供践行这些价值观的场合，例如回顾会需要开放与勇气。 |
| 事件与看板、站会等实践 | 看板是一种可视化工作流的方法，站会是短会形式；它们可以作为工具或做法服务于Scrum事件，例如用看板支撑每日Scrum的进展对齐，但本身不等同于Scrum事件的定义。 |
需要强调的是，事件是Scrum框架的组成部分，而不是整个框架。角色、工件、规则与事件共同构成Scrum；只把五个会开齐，并不等于实施了Scrum。反过来，团队采用看板等其他方法时，也可能有类似的检视节奏，但那属于另一套实践体系，不应直接套用Scrum事件的名称与规则。
一个Sprint周期的事件实例与常见误解
以一个两周Sprint为例，可以直观看到五个事件的时间安排。以下时长为示例，团队可依据Sprint长度和实际情况在框架建议范围内调整。
- 第1天上午：Sprint规划，约2–4小时，确定Sprint目标与Sprint待办事项。
- 第1天至第10天：每个工作日固定时间召开每日Scrum，15分钟，围绕Sprint目标同步进展与阻碍。
- 第10天下午：Sprint评审，约1–2小时，向干系人展示增量并收集反馈，更新产品待办事项。
- 第10天评审之后：Sprint回顾，约1–1.5小时，检视协作过程，形成改进项。
- 随后进入下一个Sprint规划，带着更新后的待办事项和上一轮的改进项开始新一轮循环。
实际运行中，三个误解最常见。把每日Scrum当成汇报会，表现为成员逐一向管理者陈述进度，会议变长、变成单向汇报。正确的理解是，每日Scrum由开发人员主导，用于彼此对齐和调整当天计划，重点在协作而非汇报。
把Sprint评审当成演示会，表现为团队花大量时间准备展示材料，干系人只看不反馈，评审结束没有对待办事项产生任何影响。正确的理解是，评审的核心是检视增量并据此调整下一步工作，展示只是手段，反馈和更新才是产出。
把Sprint回顾当成追责会，表现为复盘变成找谁出错，成员因此回避真实问题，改进项流于形式。正确的理解是，回顾针对的是过程和协作方式，目的是找出可执行的改进，而不是评价个人。
这些误解带来的共同后果是事件空转：会开了，检视和调整却没有发生，节奏还在但闭环断了。当时间盒被突破时，处理方向是先确认事件的核心目的有没有达成，把未完成的讨论转为后续单独安排，并在下一次回顾中检查时间盒设置是否合理，而不是靠延长会议来弥补。
团队如何把这些事件落到协作工具里
事件运行起来后，真正需要被管理的是它们产生的记录与交接：Sprint规划确定的待办事项、每日Scrum暴露的阻碍、评审带来的待办更新、回顾形成的改进项。这些内容如果只停留在会议现场，下一轮规划就缺少可靠输入，改进项也容易在忙碌中被遗忘。
落到工具里，可以按角色和动作梳理一条连贯的流程。产品负责人把按优先级排好的需求规划到对应迭代，在Sprint规划中与团队共同评审需求，这一步的产出是本次迭代要完成的需求集合。迭代过程中，团队成员围绕这些需求拆解并完成任务，通过看板管理任务状态；每日Scrum借助看板对齐进度与风险，把需要排除的问题显性化。迭代完成并发布后，团队可以召开回顾会，结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差，讨论改进建议，并把经验沉淀到团队知识库中，供下一轮规划参考。
ONES在这条流程中承载的正是上述记录与状态管理动作。ONES支持经典的Scrum研发场景，产品负责人可将产品待办列表中的需求按优先级规划至对应迭代，并在迭代计划会议上与团队共同评审；迭代中团队通过敏捷看板管理任务状态，在每日站立会议中借助看板对齐进度与风险；迭代结束后可召开回顾会，通过燃尽图、工时日志、持续集成报告等报表复盘进度、质量和成本偏差，并用ONES Wiki将经验沉淀为团队知识库。对于需要兼顾组织架构、资源管理与全局进度管控的中大型团队，这些能力可以与Scrum事件的节奏配合使用。工具的作用是让事件的输入输出有据可查、可交接，事件本身的目的与规则仍由团队按Scrum框架把握。
常见问题
Sprint本身算不算Scrum事件？
算。Sprint是五个Scrum事件之一，同时是其余四个事件的容器。它有固定的起止时间和贯穿始终的Sprint目标，Sprint规划、每日Scrum、Sprint评审和Sprint回顾都发生在它内部，不能脱离它单独存在。理解这一点，就不会把Sprint只当成一个时间背景，而会把它当作需要被检视和调整的正式事件。
团队每天开的站会如果超过15分钟，还算Scrum事件吗？
每日Scrum的时间盒是15分钟，超时说明讨论偏离了同步进展与调整当天计划的核心目的。处理方向是先确认当天要调整的事项有没有说清，把需要深入讨论的问题转到会后单独安排，并在下一次回顾中检查时间盒设置和会议组织方式。延长会议本身不是解决办法，事件的目的达成比时长更重要。
需求澄清会、技术方案评审会要不要按Scrum事件来管理？
通常不需要。这类活动是团队按需组织的专业活动，服务于具体工作内容，缺少框架规定的事件目的与固定产出。它们可以安排在Sprint内，也可以借助看板或任务记录跟踪结论，但不应套用Scrum事件的名称、时间盒和参与者规则。把它们与五个事件区分开，能避免事件清单被无限扩张。
五个事件产生的待办事项和改进项，怎么保证不丢？
关键是让事件的输出有明确的记录位置和交接对象。Sprint规划确定的需求集合、每日Scrum暴露的阻碍、评审带来的待办更新、回顾形成的改进项，都需要落到可跟踪的工作项或知识条目上，并在下一轮规划时被重新读取。ONES支持产品负责人按优先级把需求规划到对应迭代，团队通过敏捷看板管理任务状态，迭代结束后用燃尽图、工时日志等报表复盘，并可用ONES Wiki沉淀经验，这些动作可以帮助事件的输入输出保持可查、可交接。
团队同时用看板方法，Scrum事件还要不要保留？
这取决于团队选择的管理框架。看板是一种可视化工作流的方法，可以作为工具支撑每日Scrum的进展对齐，但它本身不等同于Scrum事件的定义。如果团队按Scrum框架运作，五个事件的目的和时间盒应当保留；如果团队采用看板作为主要方法，可以有类似的检视节奏，但不应直接套用Scrum事件的名称与规则。混合使用时，需要明确哪些活动属于Scrum事件、哪些属于团队自发的协作安排。
