Scrum在研发团队落地，核心是把三个角色、五类事件和三类工件变成团队每周真实运转的节奏：先明确产品负责人、Scrum Master和开发团队各自对什么负责，再用Sprint把工作切成固定长度的迭代，用Sprint计划、每日站会、评审和回顾形成闭环，用产品待办列表、Sprint待办列表和增量承载工作内容，并以完成定义作为交付门槛。落地顺序建议从一个小团队、一个产品线试点开始，先跑通一个完整Sprint，再逐步固化节奏和度量。
要点总览（TL;DR）
- 先定三个角色的责任边界：产品负责人管排序与内容，Scrum Master管流程有效性与障碍清除，开发团队管每个Sprint的增量交付。
- 把Sprint作为容器，计划会、每日站会、评审、回顾按固定时间盒排进研发日历，并让每个事件的产出成为下一个事件的输入。
- 产品待办列表保持已排序、已澄清，Sprint待办在看板上每日更新，完成定义作为增量能否展示的统一门槛并随成熟度逐步提高。
- 落地从五到九人的单产品线试点开始，跑通一个完整Sprint后再复制，重点看事件产出是否被下游真正使用。
- 第二到第三个Sprint结束时按角色、事件、工件三个维度逐项检查，出现连续无可演示增量等阻断项时回到对应维度重建产出。
落地前先定清楚：Scrum三个角色各自负责什么
Scrum落地的第一件事是分清责任，而非先买工具或先开会。三个角色分别对应三种责任：产品负责人对“做什么、先做哪个”负责，Scrum Master对“流程是否有效、障碍是否被清除”负责，开发团队对“每个Sprint交出可用的增量”负责。三者边界清晰，后续的事件和工件才有稳定的输入输出。
产品负责人是产品待办列表的唯一责任人，负责条目的内容、可见性和优先级排序。判断产品负责人是否到位，看两件事：团队能否在计划会上拿到已排序、已澄清的条目；需求变更是否经过同一个人重新排序，而不是由多方各自插单。产品负责人可以借助业务方、用户研究输入，但排序结论必须收敛到一个人。
Scrum Master的职责是保障流程有效性：组织并守护各类事件的时间盒，帮助团队识别和清除障碍，推动团队形成自组织能力。Scrum Master不替团队分配任务，也不替产品负责人排序。常见越界是把Scrum Master做成“项目管理员”，只催进度、记会议纪要，障碍却停留在口头。
开发团队对Sprint增量的交付负责，包括把产品待办条目拆解为Sprint待办、自行认领和拆解任务、在Sprint内完成开发与自测。开发团队应是跨职能的，具备把一个条目做到“完成”所需的技能组合；人数通常控制在能高效协作的范围内，规模过大时先拆分为多个团队，再协调依赖。
| 角色 | 核心职责 | 关键产出 | 常见越界 |
|---|---|---|---|
| 产品负责人 | 对待办列表的内容与价值排序负责，决定Sprint目标 | 已排序、已澄清的产品待办列表；Sprint目标 | 把排序权下放给多方；只写需求不参与评审反馈 |
| Scrum Master | 保障流程有效性，清除障碍，推动自组织 | 事件按时间盒运行；障碍清单及处理结果 | 替团队派活；把流程问题当个人问题处理 |
| 开发团队 | 对Sprint增量交付负责，自行拆解与认领任务 | Sprint待办列表；可验收的增量 | 等待指令再行动；把未完成项默认顺延而不说明 |
角色兼任与专职的取舍取决于团队规模和产品复杂度。小团队初期可以由一人兼任Scrum Master与开发工作，但产品负责人的价值排序责任不宜与开发交付责任混同，否则容易出现“自己排优先级、自己说做不完”的失衡。团队规模扩大、跨团队依赖增多时，Scrum Master逐步转为专职，产品负责人也需要有稳定的时间投入。
五类事件怎么排进研发日历：从Sprint计划到回顾
Sprint是容器，其余四类事件都发生在Sprint内部，形成“计划—执行—评审—回顾”的闭环。Sprint长度一旦确定就应保持稳定，常见选择是两周；长度稳定的意义在于团队能形成可预期的节奏，度量数据也具备可比性。事件排期的关键是让每个事件的产出成为下一个事件的输入。
Sprint计划会确定Sprint目标和Sprint待办列表，输入是已排序的产品待办列表和上一Sprint的增量反馈，输出是团队承诺的Sprint目标与任务拆解。每日站会同步进展与障碍，输入是看板上的任务状态，输出是当天协作安排和需要Scrum Master跟进的障碍。Sprint评审向利益相关方展示增量并收集反馈，输出是待办列表的调整意见。Sprint回顾检视流程本身，输出是下个Sprint要落实的改进项。
| 事件 | 时间盒（以两周Sprint为例） | 参与人 | 产出 |
|---|---|---|---|
| Sprint计划会 | 不超过4小时 | 产品负责人、Scrum Master、开发团队 | Sprint目标、Sprint待办列表 |
| 每日站会 | 每天不超过15分钟 | 开发团队，Scrum Master列席 | 当日协作安排、障碍清单 |
| Sprint评审 | 不超过2小时 | 团队及关键利益相关方 | 增量演示、待办列表调整意见 |
| Sprint回顾 | 不超过1.5小时 | 团队与Scrum Master | 改进项及负责人 |
与既有会议合并时要守住事件的产出，而不是守住会议名称。团队原有的周会如果承担了进度同步功能，可以用每日站会替代其同步部分，周会保留跨团队协调议题；原有的需求评审会可以与Sprint评审衔接，但评审必须展示可运行的增量，而非只过文档。合并的原则是：一个会议只承担一类产出，避免把计划、汇报、评审混在一次长会里。
三类工件与完成定义：让工作内容可追踪、可验收
三类工件分别回答三个问题：产品待办列表回答“要做什么、先做什么”，Sprint待办列表回答“这个Sprint具体怎么做”，增量回答“已经做成了什么”。完成定义则是判断增量是否真正完成的统一门槛，三者配合才能让工作内容可追踪、可验收。
产品待办列表的条目粒度以“一个Sprint内能被团队做到完成”为宜，过大的条目在计划会前需要拆分。排序原则围绕价值、风险和依赖展开：高价值且能验证假设的条目优先，存在技术不确定性的条目尽早做以降低风险，有前置依赖的条目按依赖顺序排列。条目需要写清验收条件，否则计划会容易变成需求澄清会。
Sprint待办列表是团队对Sprint目标的承诺载体，在迭代中允许更新：任务拆解可以细化，发现遗漏可以补充，但Sprint目标的变更需要与产品负责人协商。更新应发生在看板上，让状态变化对全员可见，而不是停留在个人记录里。每日站会围绕看板对齐，障碍单独记录并跟踪到关闭。
增量与完成定义的对应关系是验收的核心：只有满足完成定义全部条目的工作，才计入增量并可以在评审中展示。完成定义应随团队成熟度逐步提高门槛，初期先覆盖可验收的基本质量项，例如代码评审通过、单元测试覆盖关键逻辑、在测试环境验证通过；团队稳定后再补充自动化回归、性能基线、安全扫描等要求。门槛提高的时机应选在团队连续几个Sprint稳定达标之后，避免一次性抬高导致交付失速。
完成定义检查条目示例：代码已合并至主干并通过评审；相关单元测试与集成测试通过；在类生产环境完成功能验证；接口文档与变更说明已更新；无已知阻断级缺陷遗留。工件维护规则可以写成三条：产品待办列表每周至少梳理一次并保持排序有效；Sprint待办列表每日随站会更新状态；完成定义每次调整都在回顾会上确认并记录版本。
当团队把待办列表、看板和完成定义放到同一套协作工具中时，状态变化和验收记录可以自然衔接。ONES 为需求管理、迭代规划、进度跟踪、迭代复盘等环节提供工具支撑，团队可以围绕迭代需求拆解任务，并通过敏捷看板管理任务状态；迭代结束后可借助燃尽图、工时日志等报表复盘进度与质量偏差，并用 ONES Wiki 沉淀回顾结论。其自定义与组件化配置能力，便于团队按自身工作习惯调整流程，具体可用模块以实际版本为准。
第一个Sprint怎么跑：从零到闭环的操作步骤
第一个Sprint的目标是跑通闭环，而非追求交付量。试点范围建议选一个产品线、一个五到九人的研发团队，选择标准是业务相对独立、利益相关方愿意参与评审、团队负责人支持投入时间。范围过大时，第一个Sprint很容易被跨团队依赖拖住，难以形成完整闭环。
启动前的准备包括三件事：产品负责人整理出覆盖未来两三个Sprint的产品待办列表初稿并完成排序；团队共同起草一版完成定义初稿，条目控制在可执行的范围内；确定看板与协作工具，建立Sprint待办列表的承载位置。准备工作以“够用”为准，不必等到待办列表完美再启动。
- 确定试点范围与角色。输入：产品线范围和团队名单。动作：明确产品负责人、Scrum Master和开发团队成员，书面记录职责边界。输出：角色任命与职责说明。完成标志：三人角色均有明确人选，团队知晓各自责任。
- 准备待办列表与完成定义初稿。输入：业务需求、历史缺陷、技术改进项。动作：产品负责人完成条目编写与排序，团队评审完成定义初稿。输出：已排序的产品待办列表、完成定义初稿。完成标志：前两个Sprint的候选条目具备验收条件。
- 搭建看板与工作项结构。输入：团队工作流。动作：配置待办、进行中、待验证、完成等状态列，建立需求与任务的关联方式。输出：可用的Sprint看板。完成标志：团队能在看板上看到全部Sprint待办条目。
- 召开第一个Sprint计划会。输入：已排序的待办列表、团队产能估算。动作：产品负责人说明条目价值与优先级，团队确认Sprint目标并拆解任务，逐条确认验收条件。输出：Sprint目标、Sprint待办列表。完成标志：每个任务有负责人和预估，团队对目标达成一致。
- 执行Sprint并运行每日站会。输入：Sprint待办列表。动作：每日围绕看板同步进展，障碍由Scrum Master记录并跟进。输出：更新的任务状态、障碍清单。完成标志：站会控制在15分钟内，障碍有明确跟进人。
- 召开Sprint评审。输入：满足完成定义的增量。动作：团队演示可运行的功能，利益相关方给出反馈，产品负责人据此调整待办列表。输出：评审反馈、待办列表调整记录。完成标志：增量在类生产环境可演示，反馈已记录。
- 召开Sprint回顾并落实改进项。输入：本Sprint的事件记录、度量数据、团队观察。动作：团队讨论做得好的与需要改进的，选出下个Sprint要落实的一到两项改进并指定负责人。输出：改进项清单。完成标志：改进项进入下个Sprint的待办或团队工作约定。
第一个Sprint结束后，用同一套步骤再跑一轮，重点观察事件产出是否被下一个事件真正使用。若计划会的输出在站会上无人参照，说明待办列表与看板脱节；若评审反馈没有进入待办列表，说明闭环在评审处断开。这些信号比交付数量更能说明落地质量。
落地示例：一个十人研发团队的前两个Sprint
以下为演示情景，用于说明角色、事件与工件如何配合，不代表真实客户案例。某研发团队共十人，负责一条内部业务系统的持续迭代，团队此前按季度排期、按月汇报进度。团队指定一名产品负责人对接业务方，一名开发骨干兼任Scrum Master，其余八人组成开发团队，Sprint长度定为两周。
第一个Sprint启动前，产品负责人整理出约二十条待办条目并完成排序，团队用半天时间起草完成定义，包含代码评审、单元测试、测试环境验证三项。计划会上，团队选定“完成订单查询性能优化与两个高频缺陷修复”作为Sprint目标，拆解出十四项任务。执行中每日站会控制在十分钟左右，暴露出两个障碍：测试环境不稳定、部分条目验收条件不清。Scrum Master跟进环境问题，产品负责人在站会后补充验收条件。评审时团队演示了优化后的查询响应和缺陷修复结果，业务方提出一项新的报表需求，产品负责人将其排入待办列表。回顾会上团队识别出两个问题：条目在计划会前澄清不足，导致会上耗时过长；任务预估偏乐观，Sprint末有两条任务未完成。
第二个Sprint的调整集中在三处：产品负责人在计划会前组织一次条目澄清，确保候选条目具备验收条件；团队在计划会上为每项任务预留缓冲，并按“必须完成”和“可以延后”区分Sprint待办；Scrum Master在站会上固定询问障碍，将环境类问题纳入跟踪清单。第二个Sprint按计划完成目标，评审反馈当天即进入待办列表，回顾会只保留一项改进：把测试环境验证提前到开发完成后的当天进行。
这个示例中可迁移的规律有三条：第一，第一个Sprint的问题大多出在输入质量而非团队能力，澄清和排序的前置投入直接决定计划会效率；第二，改进项要少而具体，一次回顾落实一到两项比列出十条更有效；第三，评审反馈必须当天进入待办列表，否则闭环会在下一次计划会前失效。
落地过程中的常见偏差与纠正动作
Scrum落地初期的偏差大多表现为“形式做了、产出没变”。识别偏差的方法是看事件的产出是否被下游使用：站会如果没有产生当天的协作调整，评审如果反馈没有进入待办列表，就说明事件在空转。纠正动作应针对产出，而非增加会议或加强督促。
| 偏差 | 典型表现 | 纠正动作 |
|---|---|---|
| 站会变成汇报会 | 成员逐一向Scrum Master汇报进度，会议超过15分钟 | 改为围绕看板从左到右过条目，只讨论阻塞与协作；Scrum Master不逐人追问 |
| 评审变成演示会 | 只展示截图或文档，利益相关方不提问，反馈不落地 | 要求演示可运行增量，评审结束当场确认待办列表调整，并记录负责人 |
| 产品负责人缺位 | 计划会上无人能定优先级，需求由多方插单 | 明确排序权归属一人，建立插单需重新排序的规则；产品负责人固定参加计划会与评审 |
| 完成定义被绕过 | 未测试的条目计入增量，评审时以“下个Sprint补”解释 | 评审只展示满足完成定义的条目；未达标条目退回待办列表并说明原因 |
| 度量被当作考核 | 用燃尽图、工时对比个人绩效，团队开始修饰数据 | 明确度量用于流程诊断，数据在团队内讨论；考核指标与迭代数据分离 |
产品负责人缺位或排序失灵时，先判断是权限问题还是时间问题。权限问题需要向上明确排序权归属，建立变更入口；时间问题则需要产品负责人减少并行事务，把计划会前的澄清和排序作为固定投入。完成定义被绕过时，处理重点在评审环节：把“满足完成定义”作为展示的前置条件，比事后追责更能稳定门槛。度量被误用时，团队负责人应公开说明数据用途，并把改进讨论限定在流程层面。
落地完成检查：判断Scrum是否真正运转起来
判断Scrum是否落地，不看会议是否开齐，而看角色、事件、工件三个维度是否形成稳定产出并被下游使用。检查建议在第二到第三个Sprint结束时进行，由Scrum Master组织，产品负责人和团队负责人共同确认，之后每个季度复核一次。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 角色职责清晰 | 三人角色均有明确人选，排序权与流程责任无混同 | 角色职责说明、待办列表排序记录 | 团队负责人 |
| 事件按节奏运行 | 四类事件按时间盒召开，产出被下一事件使用 | 事件日历、计划会与评审记录 | Scrum Master |
| 待办列表有效 | 条目具备验收条件，排序在Sprint间保持更新 | 待办列表变更记录 | 产品负责人 |
| Sprint待办可追踪 | 任务状态每日更新，障碍有跟进记录 | 看板状态、障碍清单 | 开发团队 |
| 完成定义被执行 | 评审展示的增量均满足完成定义，未达标项退回 | 评审记录、完成定义版本 | 开发团队 |
| 回顾改进有落实 | 上个Sprint的改进项在本Sprint有可见变化 | 回顾记录与改进项状态 | Scrum Master |
出现以下情况时应判定为阻断项并回退重做：连续两个Sprint的评审没有可演示增量；产品待办列表长期无排序或由多人各自插单；完成定义被反复绕过且无纠正记录。回退的做法不是推翻全部流程，而是回到对应维度重新建立产出，例如重新确认产品负责人并恢复排序机制，或与团队重新约定完成定义并在一轮Sprint中严格执行。
检查通过后，团队可以把精力转向节奏优化：稳定Sprint长度、逐步提高完成定义门槛、让度量数据服务于流程诊断。Scrum在研发团队的落地是一个持续校准的过程，角色、事件和工件三者保持产出衔接，流程才算真正运转起来。
常见问题
团队规模很小，产品负责人和Scrum Master可以由同一个人兼任吗？
小团队初期可以让一人兼任Scrum Master与开发工作，但产品负责人的价值排序责任建议保持独立。排序权与交付责任集中在同一人身上时，容易出现优先级随交付压力临时调整、Sprint目标反复变动的情况。若人手确实紧张，至少要把“谁对排序做最终决定”书面明确，并保证需求变更经过同一入口重新排序。
团队已有周会和需求评审会，是否必须全部取消再新建Scrum事件？
不必全部取消，关键是按产出合并而不是按会议名称合并。原有周会若主要承担进度同步，可以由每日站会承接同步部分，周会保留跨团队协调议题；需求评审会可以与Sprint评审衔接，但评审环节要展示可运行的增量。合并时守住一条原则：一个会议只承担一类产出，避免计划、汇报、评审混在一次长会里，导致每个产出都不完整。
完成定义应该定得多严？一开始就要求自动化测试和性能基线吗？
完成定义的门槛应与团队当前稳定达成的水平匹配。初期先覆盖可验收的基本质量项，例如代码评审通过、关键逻辑有单元测试、在测试环境验证通过；等团队连续几个Sprint稳定达标后，再逐步补充自动化回归、性能基线、安全扫描等要求。一次性把门槛抬得过高，常见结果是条目无法在Sprint内完成，团队转而绕过完成定义，反而削弱了它的约束力。
Sprint进行中业务方提出紧急需求，应该插进当前Sprint吗？
先判断紧急需求是否影响当前Sprint目标的达成。若不影响，交由产品负责人排入产品待办列表，在下一个Sprint计划会上统一处理；若确实影响目标，需要产品负责人与团队协商调整Sprint目标，并明确被替换出的条目去向，而不是简单追加任务。无论哪种处理，插单都应经过产品负责人这一入口重新排序，避免多方各自插入导致Sprint待办失控。
燃尽图、工时等数据可以用来考核团队成员吗？
不建议把迭代度量直接用于个人考核。燃尽图、工时日志反映的是流程和估算的整体状况，一旦与个人绩效挂钩，团队容易倾向于修饰数据，度量就失去了诊断价值。更合适的做法是把这些数据限定在团队内讨论，用于识别估算偏差、障碍积压和流程瓶颈，考核指标与迭代数据分开设计。
