Scrum工件在研发团队落地，关键是把Product Backlog、Sprint Backlog和增量这三类工件的责任人、必填字段和状态规则先定清楚，再放进一个Sprint里跑通。本文给出一页工件规则表、一个Sprint的操作步骤、角色交付物对照、填写示例和完成检查清单，帮助团队从“建了列表”走到“按规则使用”。
要点总览（TL;DR）
- 先写一页工件规则表，明确Product Backlog、Sprint Backlog和增量各自的责任人、必填字段、状态流转和更新时点，规则要具体到字段名和状态名。
- 把规则放进一个Sprint跑通：Planning中挑选、拆解、认领，站会更新剩余工作量，Review对照Sprint目标和DoD验收，Retrospective把问题回补成规则修改。
- 角色边界按“做什么、怎么拆、规则是否执行”划分：产品负责人维护排序与验收口径，开发团队拆解并更新Sprint Backlog，Scrum Master保障规则执行与修订。
- 用完成定义（DoD）作为增量的统一验收口径，写成可勾选检查项；单条目的特殊条件写在Product Backlog的验收口径字段，两者分开。
- 每个Sprint核对一次工件使用情况，重点纠正工件只建不用、字段冗余和状态长期不更新三类偏差。
先定三类工件的责任人与字段规则
落地第一步是写出一页《Scrum工件规则表》，让团队任何人拿到它都能判断：这条内容该记在哪个工件里、由谁维护、填哪些字段、状态怎么变、什么时候更新。规则表不需要长，但要具体到字段名称和状态名称，避免“按需填写”“及时更新”这类无法执行的表述。
三类工件的定位不同。Product Backlog是待办事项的唯一来源，由产品负责人维护，按价值排序，每条写清验收口径；Sprint Backlog是当前Sprint的工作承诺，由开发团队在Sprint Planning中拆解并认领，对应到可交付的增量；增量是Sprint结束时可供评审的成果，以Sprint目标为验收对象，用完成定义（DoD）判断是否真正完成。
| 工件 | 责任人 | 必填字段 | 状态流转 | 更新时点 |
|---|---|---|---|---|
| Product Backlog | 产品负责人维护，全员可读 | 标题、价值说明、验收口径、优先级、估算、依赖 | 待梳理→已就绪→已排入Sprint→已完成/已关闭 | 每次梳理会后、Sprint Planning前 |
| Sprint Backlog | 开发团队拆解与认领，Scrum Master保障规则执行 | 关联的Product Backlog条目、任务描述、负责人、剩余工作量、状态 | 待开始→进行中→待验证→已完成 | 每日站会前后更新剩余工作量与状态 |
| 增量 | 开发团队交付，产品负责人验收 | Sprint目标、包含的条目、DoD检查结果、验证记录 | 构建中→待评审→已验收/未达DoD | Sprint Review前完成自检，Review中确认 |
完成定义（DoD）是增量验收的统一口径，建议写成可勾选的检查项，例如“代码已合并主干”“单元测试通过”“验收口径逐条验证”“相关文档已更新”。DoD由团队共同约定，对所有条目一致适用；单条目的特殊验收条件写在Product Backlog的验收口径字段里，两者分开，避免每次验收重新讨论标准。
字段设计要克制。必填字段只保留支撑排序、拆解和验收所必需的信息，其余作为选填。字段越多，维护成本越高，团队越容易只建不用。状态名称也要少而明确，每个状态对应一个可观察的动作，例如“待验证”意味着开发自测完成、等待测试或产品确认。
按Sprint节奏落地工件的操作步骤
规则表定好后，选一个团队、一个Sprint做验证。下面按Sprint的时间顺序列出每个环节的输入、动作、输出和完成标志，团队可以照此执行并记录偏差。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| Sprint Planning | 已就绪的Product Backlog条目、上一Sprint增量、团队速率参考 | 产品负责人讲解条目与验收口径；开发团队挑选本Sprint可完成的条目，拆解为任务并认领，填写剩余工作量；共同确认Sprint目标 | Sprint Backlog、Sprint目标 | 每条Sprint Backlog条目都关联到Product Backlog条目并有负责人和估算 |
| 每日站会 | Sprint Backlog当前状态 | 成员更新任务状态与剩余工作量，标记阻塞；Scrum Master记录需要协调的问题 | 更新后的Sprint Backlog、阻塞清单 | 剩余工作量反映当天实际情况，阻塞有跟进人 |
| Sprint Review | 符合DoD的增量、Sprint目标 | 开发团队演示增量，产品负责人对照Sprint目标和验收口径逐条确认；未达DoD的条目回到Product Backlog | 验收结论、Product Backlog调整 | 每个条目有明确的“已验收”或“未达DoD”结论 |
| Retrospective | 本Sprint的工件使用情况、Review结论 | 团队讨论哪些字段没人填、哪些状态长期不动、哪些规则执行困难，形成具体改进项 | 改进项及责任人 | 改进项落到规则表的具体修改，而不是笼统的“加强沟通” |
Sprint Planning中从Product Backlog生成Sprint Backlog，核心动作是“挑选—拆解—认领”。挑选依据是条目的就绪程度和团队容量；拆解粒度以单个任务能在一个Sprint内完成、能被一个人负责为准；认领由开发团队自己完成，产品负责人不指派任务。拆解完成后回看一遍：每条Sprint Backlog都能追溯到某个Product Backlog条目，Sprint目标能用一句话说清本Sprint交付什么。
每日更新Sprint Backlog剩余工作，重点在“剩余”而不是“已完成百分比”。成员在站会前把任务状态推进到实际位置，并调整剩余工作量；如果某任务连续两天剩余量不变，应在站会上说明原因。状态更新时点固定在站会前后，避免一天内反复改动造成信息噪声。
Sprint Review用增量对照Sprint目标验收。演示顺序按条目走，每条展示实际可运行的结果，产品负责人对照验收口径和DoD给出结论。未达DoD的条目不进入增量，回到Product Backlog并补充说明缺口，这比在Review上临时放宽标准更能保护工件可信度。
Retrospective的产出要回补工件规则。回顾时收集三类证据：字段填写缺失的记录、状态停留过久的条目、Review中反复出现的验收争议。每类证据对应一条规则修改，例如“验收口径字段改为必填”“取消某个无人使用的选填字段”“在DoD中增加文档更新检查项”。修改后的规则表在下一个Sprint生效，形成“执行—回顾—修订”的循环。
当团队希望把上述规则承载在工具中时，ONES 敏捷研发管理解决方案提供了对应的工作项与看板能力：需求可编写并自定义状态与属性，规划至迭代并分配负责人；迭代中成员拆解任务并通过敏捷看板管理状态，站会时用看板对齐进度与风险；测试环节可依据需求与验收标准编写用例，未通过用例转为缺陷指派修复。这些能力对应的是工件规则的承载，规则本身仍需团队先定义清楚。
角色分工与各环节交付物
工件无人维护或重复维护，通常源于职责边界不清。按角色划分，产品负责人对“做什么、先做哪个、怎样算合格”负责，开发团队对“怎么拆、谁来做、做到哪”负责，Scrum Master对“规则是否被执行、是否在改进”负责。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 维护Product Backlog，按价值排序，为每条写清验收口径；在Planning中讲解条目；在Review中给出验收结论 | 排好序且就绪的Product Backlog、验收结论、Review后的条目调整 |
| 开发团队 | 在Planning中拆解并认领任务；每日更新Sprint Backlog状态与剩余工作量；按DoD交付增量 | Sprint Backlog、每日更新记录、符合DoD的增量 |
| Scrum Master | 保障工件规则被遵守；组织规则表的制定与修订；跟踪阻塞与改进项 | 工件规则表、阻塞清单、Retrospective改进项及跟进记录 |
Review和Retrospective是两个角色交付物集中产出的场合。Review中，产品负责人交付验收结论和Product Backlog调整，开发团队交付可演示的增量；Retrospective中，Scrum Master交付改进项清单和规则修订建议，开发团队与产品负责人共同确认下一Sprint要执行的修改。两个会议的产出都应落到具体工件上，而不是只停留在会议记录里。
需要避免的重复维护是：产品负责人在Product Backlog里写任务级细节，开发团队又在Sprint Backlog里重写一遍需求描述。正确做法是Sprint Backlog只引用Product Backlog条目，补充任务拆解和负责人，需求描述与验收口径保持单一来源。同样，DoD只在团队层面维护一份，不按条目各写一套。
一个研发团队的落地示例
以下示例为演示情景，用于说明字段和状态如何填写，团队可按自身业务替换内容。
Product Backlog条目写法。某研发团队维护一个订单系统，条目示例为：“支持订单批量导出——价值：客服每月手工整理订单约两天工作量；验收口径：单次可导出不少于5000条、导出字段与列表一致、导出失败有明确提示；优先级：高；估算：5；依赖：无；状态：已就绪。”这条记录写清了价值、验收口径和优先级，开发团队在Planning时无需再向产品负责人追问“做到什么程度算完成”。
Sprint Backlog拆解与认领示例。该条目进入Sprint后拆为四个任务：导出接口设计（负责人A，剩余8小时）、导出服务实现（负责人A，剩余16小时）、导出失败提示与前端入口（负责人B，剩余8小时）、导出性能与字段一致性验证（负责人C，剩余6小时）。每个任务关联到该Product Backlog条目，状态从“待开始”推进到“进行中”，站会时更新剩余工作量。
增量验收与DoD对照示例。Sprint Review前，团队按DoD自检：代码已合并主干、单元测试通过、验收口径逐条验证、相关文档已更新，四项均勾选。Review中演示5000条导出、字段比对和失败提示，产品负责人对照验收口径确认通过，条目状态置为“已验收”，增量状态从“待评审”变为“已验收”。若性能验证未通过，则该条目状态为“未达DoD”，回到Product Backlog并注明缺口。
Retrospective后规则调整示例。回顾发现“依赖”字段整个Sprint无人填写，而“导出性能与字段一致性验证”任务因缺少测试环境说明被阻塞两天。团队决定：取消“依赖”必填，改为选填；在Sprint Backlog中增加“环境需求”选填字段；在DoD中增加“验证环境已就绪”检查项。修订后的规则表在下一Sprint执行。
在工具承载上，ONES Project 支持编写需求、自定义需求状态与多种属性，并将需求和相关任务规划至迭代、分配负责人；迭代回顾时可结合燃尽图、工时日志等报表复盘进度与质量偏差，并用 ONES Wiki 沉淀规则表和回顾结论，使规则修订有据可查。
落地完成检查与常见偏差
判断工件是否真正落地，不看列表建得多完整，而看团队能否在没有外部推动的情况下按规则执行。以下清单可逐项核对，每项给出通过标准。
| 检查项 | 通过标准 | 未通过时的纠正方向 |
|---|---|---|
| 工件规则可被独立执行 | 新成员仅凭规则表就能判断条目该记在哪、填哪些字段、状态怎么变 | 把模糊表述改为具体字段名和状态名，删除无人使用的字段 |
| Sprint Backlog与增量对应 | 每条Sprint Backlog都能追溯到Product Backlog条目，Review演示内容与Sprint Backlog一致 | Planning时补做追溯检查，未关联的条目移出Sprint |
| DoD被实际用于验收 | Review中逐项核对DoD，未达项有明确结论和回退记录 | 把DoD做成可勾选检查项，Review记录中保留核对结果 |
| 状态反映真实进展 | 状态变化与站会描述一致，无长期停留不动的条目 | 站会固定更新时点，对停留过久的条目单独说明原因 |
常见偏差有三类。第一类是“工件只建不用”：Product Backlog建得很全，但Planning时不看、Review时不对照，工件与决策脱节。纠正方向是把工件作为会议输入固定下来，例如Planning必须从已就绪条目中挑选，Review必须对照验收口径。第二类是“字段冗余”：字段越加越多，团队填不动，最后大面积留空。纠正方向是每个Sprint回顾一次字段使用率，连续两个Sprint无人使用的字段改为选填或删除。第三类是“状态长期不更新”：任务实际已完成，状态仍停在“进行中”，导致看板和燃尽图失真。纠正方向是把状态更新纳入站会动作，并让状态与验收结论挂钩，未更新状态的条目不能在Review中计为完成。
检查的频率建议与Sprint节奏一致：每个Sprint Review后核对一次前两项，Retrospective中核对后两项并决定规则修订。连续两到三个Sprint保持通过，说明工件规则已经嵌入团队日常动作，可以再考虑扩大适用范围或细化字段。
常见问题
团队刚开始落地Scrum工件，应该先做规则表还是先上工具？
先做规则表。规则表要回答的是这条内容记在哪个工件、由谁维护、填哪些字段、状态怎么变，这些是团队共识，工具只是承载方式。规则没定清楚就上工具，常见结果是字段照搬模板、没人知道该填什么，最后大面积留空。
建议先用一个Sprint在轻量方式下跑通规则，确认字段和状态确实够用、团队能执行，再把规则配置到工具中。ONES Project 支持自定义需求状态与多种属性，可作为规则确定后的承载方式，具体字段配置以实际项目设置为准。
Product Backlog的验收口径和DoD有什么区别，能不能合并成一份？
两者作用范围不同，建议分开维护。DoD是团队层面的统一完成标准，对所有条目一致适用，例如代码合并、测试通过、文档更新；验收口径是单条目的特殊条件，说明这条需求做到什么程度算合格，例如导出条数、字段一致性要求。
合并成一份会带来两个问题：DoD被逐条改写，失去统一口径的作用；或者单条目的特殊条件被忽略，Review时反复争论标准。做法是DoD只维护一份，验收口径写在Product Backlog条目字段里，Review时两者都核对。
Sprint进行到一半，发现某条Sprint Backlog做不完，应该怎么处理？
先判断是范围问题还是执行问题。如果是条目本身超出本Sprint容量，由开发团队与产品负责人沟通，把该条目移出Sprint Backlog、回到Product Backlog，并在站会记录中说明原因；如果是执行受阻，明确阻塞项和跟进人，在站会上持续跟踪。
无论哪种情况，都要保持Sprint Backlog与增量的对应关系：Review演示的内容应当来自Sprint Backlog，移出的条目不进入本次增量，也不在Review中临时补做。Sprint目标是否需要调整，由团队与产品负责人共同确认。
Retrospective提出的改进项，怎么避免停留在会议记录里？
把改进项转成规则表的具体修改，并指定生效时间。例如“加强验收”不是可执行的改进项，“在DoD中增加验证环境已就绪检查项，下个Sprint生效”才是。每条改进项写清改哪个工件的哪个字段或状态、由谁改、从哪个Sprint开始执行。
下一个Retrospective先核对上一轮改进项的执行情况，未执行的说明原因。ONES Wiki 可用于沉淀规则表和回顾结论，让规则修订有据可查；规则本身是否被执行，仍要靠团队在Sprint中核对。
工件落地到什么程度算完成，需要一直检查下去吗？
判断标准是团队能否在没有外部推动的情况下按规则执行：新成员凭规则表就能判断条目该记在哪、填哪些字段；Sprint Backlog每条都能追溯到Product Backlog条目；Review中逐项核对DoD；状态变化与站会描述一致。
检查频率建议与Sprint节奏一致，Review后核对工件与增量的对应关系，Retrospective中核对字段使用率和状态更新情况。连续两到三个Sprint保持通过，说明规则已嵌入日常动作，可以把检查频率降低，转为按需复核。
