Scrum工件落地的关键，是让Product Backlog、Sprint Backlog和增量成为团队每天真正使用的对象，而非只在评审前补写的文档。本文面向研发团队的Scrum Master、Product Owner和技术负责人，给出从建清单到产出可交付增量的分步操作、角色分工、字段模板与检查清单。迭代会议的具体组织与需求池的长期治理不在本文展开。
要点总览（TL;DR）
- 三件工件各司其职：Product Backlog 管“接下来做什么”，Sprint Backlog 管“本迭代怎么拆”，增量管“交付了什么可用成果”，三者按排序—拆解—汇入—回写的顺序衔接。
- 落地按四步推进：建清单并定字段与排序规则、规划时拆出 Sprint Backlog、迭代中更新状态与阻塞、Sprint 末形成增量并评审，每步都有可核对的完成标志。
- 角色边界要写清：Product Owner 对清单内容与排序负责，开发团队对任务拆解与增量质量负责，Scrum Master 对工件透明性与流程机制负责，规划会和评审会是两个关键交接点。
- 字段与完成定义服务于“能不能明确说完成了”：条目保留描述、验收条件、优先级，任务拆到一人一天可完成，完成定义写可核验的事实并在回顾中定期检视。
- 用检查清单判断落地程度：需求单一来源、状态及时更新、条目可判断完成、增量可评审、评审结论回写，出现失效信号先查字段负担与责任分工。
三件工件各自解决什么问题
三件工件对应研发流程中三个不同的问题：做什么、这个迭代怎么做、做出来什么。把职责分清，团队才不会把所有信息堆在一张清单里，也不会在迭代末期才发现没有可评审的成果。
Product Backlog 是需求的唯一入口，回答“接下来值得做什么”。它承载需求来源、价值判断和排序依据，由 Product Owner 负责内容与顺序。Sprint Backlog 回答“这个迭代团队承诺做什么、怎么拆”，它是 Product Backlog 中选定条目加上交付计划，由开发团队在迭代内维护。增量回答“这个迭代结束时有什么可用成果”，它是所有已完成且满足完成定义的条目之和，是 Sprint 评审的评审对象。
三者的输入输出关系是单向递进的：Product Backlog 排序后选出迭代范围，进入 Sprint Backlog 拆解为任务；任务完成并满足完成定义后汇入增量；评审与回顾的结论再回写到 Product Backlog，形成下一轮排序的输入。
| 工件 | 回答的问题 | 负责人 | 更新时点 |
|---|---|---|---|
| Product Backlog | 接下来做什么、先做哪个 | Product Owner | 持续细化，Sprint 规划前完成排序 |
| Sprint Backlog | 本迭代承诺什么、怎么拆 | 开发团队 | Sprint 规划时建立，迭代中每日更新 |
| 增量 | 本迭代交付了什么可用成果 | 开发团队 | Sprint 末形成，评审时确认 |
落地步骤：从建清单到产出增量
落地可以按四步推进，每一步都有明确的输入、动作、输出和完成标志。团队不必一次做到完美，但四步的顺序不宜颠倒，否则排序和拆解会失去依据。
第一步：建立 Product Backlog 并确定条目字段与排序规则
输入是需求来源，包括业务方提出的诉求、用户反馈、缺陷与技改项。动作是把这些来源统一收进一份清单，为每个条目补齐描述、价值、验收条件、优先级和估算，并约定排序规则，例如按价值与成本的比值排序，或按业务截止时间排序。输出是一份字段完整、顺序明确的清单。完成标志是：团队能指着清单说出“下一个迭代优先做哪几条、为什么”。
第二步：Sprint 规划时生成 Sprint Backlog 并拆到可执行粒度
输入是排序后的 Product Backlog 顶部条目和团队产能。动作是选定本迭代范围，把每个条目拆成一天以内可完成、可分配、可判断完成的任务，并标注负责人和状态。输出是 Sprint Backlog。完成标志是：每个任务都有明确的责任人和完成判断方式，团队对迭代目标有一致理解。
第三步：迭代中更新工件状态与阻塞信息
输入是每日的实际进展。动作是开发团队成员更新任务状态，把阻塞项显式标出并说明卡在哪个环节、需要谁处理；Product Owner 同步细化后续条目，避免下个迭代规划时临时补课。输出是反映真实进度的 Sprint Backlog 和持续细化的 Product Backlog。完成标志是：看板状态与实际情况一致，阻塞项在当天被识别并有处理人。
第四步：Sprint 末形成增量并组织评审
输入是满足完成定义的已完成条目。动作是汇总可演示、可使用的成果，在评审中向利益相关方展示，收集反馈并转化为新的 Product Backlog 条目或调整既有排序。输出是增量与评审结论。完成标志是：评审有明确的接受、调整或拒绝结论，且结论已回写到清单中。
在工件维护与状态流转这一层，ONES 敏捷研发管理解决方案覆盖需求池管理、迭代规划、迭代开发、缺陷追踪、迭代进度跟进与迭代回顾等场景，把需求提出方、产品经理、研发、测试等角色连接在同一流程中。团队可以在 ONES Project 中编写需求、自定义需求状态与属性，将需求和相关任务规划至迭代并分配负责人，迭代中通过敏捷看板管理任务状态、用燃尽图观察进度。这些能力承接的是上述步骤中的记录与可视化动作，字段设计和排序规则仍需团队自己约定。
角色分工与各自交付物
工件无人维护，通常源于职责边界模糊。把三件工件的维护责任落到具体角色，并约定交接时点，能减少重复维护和信息断层。
Product Owner 对 Product Backlog 的内容与排序负责，交付物是排序清晰、字段完整的清单和每个迭代的迭代目标说明。开发团队对 Sprint Backlog 与增量质量负责，交付物是拆解到可执行粒度的任务清单和满足完成定义的增量。Scrum Master 对工件的透明性与流程机制负责，交付物是可见、可查的工件状态和按节奏运转的规划、评审、回顾安排。
| 角色 | 负责工件 | 主要交付物 | 交接时点 |
|---|---|---|---|
| Product Owner | Product Backlog | 排序后的需求清单、迭代目标 | Sprint 规划前 |
| 开发团队 | Sprint Backlog、增量 | 任务拆解、可评审的增量 | 规划时建立，评审时交付 |
| Scrum Master | 工件透明性与流程机制 | 状态可见的看板、会议节奏与改进项 | 贯穿迭代，回顾时汇总 |
交接的关键节点有两个：规划会上 Product Owner 把选定条目交给开发团队，评审会上开发团队把增量交给利益相关方。两个节点都需要留下可查的记录，避免口头交接后信息丢失。
条目字段与完成定义怎么定
字段决定条目是否可判断，完成定义决定增量是否成立。两者都应服务于“能不能明确说完成了”，字段过多会增加填写负担，过少则无法支撑判断。
Product Backlog 条目字段
建议至少包含五类信息：描述说明要解决什么问题；价值说明为什么值得做；验收条件说明怎样算做对；优先级说明排序位置；估算给出工作量参考。字段可按团队习惯增减，但描述、验收条件和优先级建议保留，它们是排序和拆解的直接依据。
Sprint Backlog 任务粒度与状态
任务粒度以“一名成员一天内能完成并说明结果”为宜，过粗无法反映进展，过细会增加维护成本。状态字段建议保持精简，例如待办、进行中、待验证、完成，并约定每个状态的进入条件。阻塞信息应作为显式标记，而不是藏在备注里。
完成定义的编写要点
完成定义描述一个条目达到“完成”时必须满足的条件，适用于团队所有条目。编写时聚焦可核验的事实，例如代码已合并、通过约定的测试、文档已更新、可在目标环境运行。完成定义应覆盖团队对质量的最低共识，特殊条目可在此基础上追加条件，但不宜为个别条目降低整体标准。
字段与完成定义的维护
字段和完成定义属于团队约定，建议在回顾中定期检视：出现反复争议的条目，说明字段或标准不够清晰；出现普遍绕过的字段，说明填写成本高于判断价值。调整时同步更新模板并告知全员，避免新旧标准并存。ONES 支持自定义需求状态与多种属性，团队可据此把约定落到条目结构上；完成定义的具体承载方式需结合团队现有实践安排。
一个研发团队的落地示例
以下为演示情景，用于说明三件工件在一个 Sprint 周期内的流转，不对应具体客户或真实项目数据。
某研发团队有 Product Owner 一名、Scrum Master 一名、开发成员五名，迭代周期两周。Product Backlog 中积累了一批需求与缺陷，按价值与紧急程度排序。
规划会上，Product Owner 说明本迭代目标，团队从清单顶部选取若干条目，逐条拆成任务并分配负责人，形成 Sprint Backlog。拆解中发现一条需求的验收条件不清晰，当场退回 Product Backlog 补充，未纳入本迭代。
迭代进行中，成员每日更新任务状态。第三天出现一个接口依赖阻塞，负责人在看板上标记阻塞并说明需要外部团队配合，Scrum Master 跟进协调，阻塞在次日解除。Product Owner 同步细化了下个迭代的候选条目。
迭代末，团队按完成定义核对已完成条目，汇总出可演示的增量。评审中利益相关方对其中一个功能提出调整意见，该意见被记录为新的 Product Backlog 条目并参与下轮排序。回顾中团队发现某字段长期无人填写，决定简化该字段。
完成检查：工件是否真正落地
判断工件是否落地，看的是它们是否被持续使用并能支撑决策，而非是否存在。以下检查项可在每个 Sprint 评审后或每月固定时点执行，由 Scrum Master 组织，Product Owner 与开发团队共同核对。
| 检查项 | 通过标准 | 阻断信号 |
|---|---|---|
| 需求是否单一来源 | 所有需求都能在 Product Backlog 中找到，无平行清单 | 存在多份互相冲突的需求表 |
| 条目是否及时更新 | 状态与实际进展一致，阻塞项当天可见 | 看板长期不动或评审前集中补填 |
| 条目是否可判断完成 | 每个条目有验收条件，任务有明确完成标志 | 完成与否依赖口头确认 |
| 增量是否可评审 | 每个 Sprint 末有可演示或可使用的成果 | 连续多个迭代无增量可展示 |
| 评审结论是否回写 | 反馈转化为条目或排序调整并有记录 | 评审意见停留在会议记录中 |
常见失效信号包括：Product Backlog 只在规划前被打开、Sprint Backlog 与实际工作脱节、完成定义被普遍绕过。出现这些信号时，先确认是字段设计过重还是责任人不明确，再决定简化结构或调整分工。检查结论应形成少量可执行的改进项，纳入下个迭代跟进。
常见问题
团队规模较小、角色由一人兼任时，工件维护怎么分工？
小团队常见 Product Owner 由产品经理兼任、Scrum Master 由技术负责人兼任。此时仍建议把三件工件的维护动作分开记录：清单排序由兼任 Product Owner 的人完成，任务拆解与状态更新由开发成员各自完成，透明性检查由兼任 Scrum Master 的人在固定时点执行。角色可以合并，但交接节点不能省，规划会上确认迭代范围、评审会上确认增量结论，这两次确认要留下记录，避免职责合并后信息只停留在个人记忆里。
Product Backlog 条目一直细化不到位，规划会总在补需求怎么办？
这通常说明细化动作没有进入日常节奏。可以把细化拆成小步：每次只处理排序靠前的若干条目，在迭代中由 Product Owner 与开发成员一起补充验收条件和估算，而不是等到规划会集中处理。规划会上遇到验收条件不清的条目，按示例中的做法退回清单、不纳入本迭代，用这个规则倒逼平时细化。若长期出现同类条目反复退回，检查字段设计是否缺少验收条件这一项。
完成定义和条目的验收条件有什么区别，需要都写吗？
完成定义是团队对所有条目共同的质量底线，例如代码已合并、通过约定测试、可在目标环境运行；验收条件是单个条目特有的“做对了什么”。两者作用不同，建议都保留：完成定义保证增量整体可用，验收条件保证这一条需求符合预期。特殊条目可在完成定义基础上追加条件，但不宜为个别条目降低整体标准。完成定义调整后要同步告知全员，避免新旧标准并存造成判断分歧。
迭代中需求频繁变更，Sprint Backlog 还能保持稳定吗？
Sprint Backlog 是开发团队在迭代内的承诺与拆解，范围调整应经过 Product Owner 与团队共同确认，而不是由单方直接改动。可行的做法是：新需求先进 Product Backlog 参与排序，确需插入当前迭代时明确换出哪一条，并在看板上留下变更记录。迭代中允许任务粒度和状态随实际进展调整，但迭代目标不宜频繁变动，否则增量评审会失去稳定的判断基准。
用工具承载工件时，哪些部分可以配置，哪些仍需团队自己约定？
工具通常能承接条目结构、状态流转和进度可视化。以 ONES 为例，ONES Project 支持编写需求并自定义需求状态与多种属性，可将需求和相关任务规划至迭代并分配负责人，迭代中通过敏捷看板管理任务状态、用燃尽图观察进度。字段具体设哪几项、排序按什么规则、完成定义包含哪些条件，属于团队约定，需要在回顾中形成并持续维护，工具只负责把这些约定固定下来。
