Scrum工件是Scrum框架中承载透明性、供团队检视与调整使用的三类正式产出：产品待办列表、Sprint待办列表和增量。它们分别回答“要做什么、本轮打算怎么做、当前交付了什么”，并各自对应产品目标、Sprint目标与完成的定义。本文说明这三类工件的定义、边界与使用机制。
要点总览（TL;DR）
- Scrum工件是框架规定的三类正式产出：产品待办列表、Sprint待办列表和增量，分别回答要做什么、本轮怎么做、当前交付了什么。
- 每类工件绑定一项承诺：产品目标对应产品待办列表，Sprint目标对应Sprint待办列表，完成的定义对应增量。
- 看板、燃尽图、需求文档和制度文件围绕工件提供支持，本身不属于三类工件。
- 工件的作用是让工作状态透明、可检视、可调整，事件提供检视节点，工件是其中被检视的对象。
- 增量在每个事项达到完成的定义时即形成，不必等到Sprint结束才出现。
Scrum工件包括哪三类，各自回答什么问题
Scrum工件共有三类，每一类都配有一项承诺。工件本身是信息的载体，承诺则给这些信息一个可检验的方向。理解Scrum工件，先要把工件、承诺和责任角色三者对齐来看。
| 工件 | 中文解释 | 对应承诺 | 主要责任角色 | 回答的核心问题 |
|---|---|---|---|---|
| 产品待办列表（Product Backlog） | 产品已知所需改进的有序清单，是产品工作的唯一来源 | 产品目标（Product Goal） | 产品负责人 | 产品要走向哪里，接下来做什么最有价值 |
| Sprint待办列表（Sprint Backlog） | 由Sprint目标、为本轮选中的产品待办事项以及交付它们的计划组成 | Sprint目标（Sprint Goal） | 开发团队，产品负责人参与协商 | 这一轮Sprint打算完成什么、怎么完成 |
| 增量（Increment） | 朝向产品目标迈出的、可用的具体一步，是可检验的工作成果 | 完成的定义（Definition of Done） | 开发团队 | 当前实际交付了什么、是否达到可用的标准 |
三类工件之间存在递进关系。产品待办列表提供候选工作，Sprint待办列表从中选取本轮要做的部分并形成计划，增量则是执行后产生的实际成果。承诺的作用是让每类工件都有明确的完成判据：产品目标让产品待办列表有方向，Sprint目标让Sprint待办列表聚焦，完成的定义让增量具备可检验的质量标准。
责任角色的划分也需要说清。产品负责人对产品待办列表的内容、排序和产品目标负责；开发团队对Sprint待办列表的执行和增量的产出负责；Sprint目标由团队在规划时共同确定。角色分工不等于其他人不能参与讨论，而是明确最终由谁对工件的状态负责。
工件的边界：哪些内容不算Scrum工件
Scrum工件是框架规定的三类正式产出，范围相对明确。实际工作中大量出现的图表、文档和工具界面，往往与工件密切相关，但本身并不属于工件。把边界划清，有助于避免把“支持工件的东西”误当成“工件本身”。
- Scrum事件不属于工件。Sprint、Sprint规划、每日站会、Sprint评审和Sprint回顾是框架规定的事件，它们为检视和调整提供固定节奏。事件使用工件，但事件本身不是工件。
- 可视化工具和辅助图表不属于工件。看板、燃尽图、累积流图等用于呈现工件状态和趋势，是观察手段。它们反映待办事项的流转或剩余工作量，但工件是背后的待办列表和增量，图表只是视图。
- 组织内部制度文档不属于工件。开发规范、质量管理制度、审批流程文件等属于组织治理内容，可能影响完成的定义如何制定，但它们本身不在三类工件之列。
- 需求文档、设计稿、测试用例等属于工作产物。这些内容可能作为产品待办事项的说明材料或增量的组成部分存在，是否算作增量的一部分，取决于完成的定义如何约定。
还需要注意表述层面的差异。Scrum指南在不同版本中对工件的描述有过调整，例如早期版本曾把“产品待办列表梳理”作为活动讨论，后续版本更强调工件与承诺的对应关系。涉及具体措辞和定义细节时，应以当前权威指南的表述为准，本文按通行表述解释框架概念。
工件如何支撑透明、检视与调整
三类工件存在的理由，是让产品工作和Sprint工作对相关人员可见、可检视、可调整。透明、检视、调整是Scrum的三个经验主义支柱，工件是这套机制得以运转的信息基础。
透明性对工件的要求
透明意味着工件状态对负责决策的人而言是清晰可读的。产品待办列表需要让产品负责人和团队看清有哪些事项、大致顺序如何；Sprint待办列表需要让团队看清本轮承诺的范围和推进情况；增量需要让相关方看清已经完成了什么。工件状态含糊，检视就会建立在错误信息上，调整也随之失准。完成的定义在这里起关键作用：它统一了“完成”的判断口径，使增量的状态不因个人理解不同而出现偏差。
工件在事件中的使用位置
工件贯穿各个事件，但每个事件的关注点不同。Sprint规划中，团队从产品待办列表中选取事项，形成Sprint待办列表并确定Sprint目标；每日站会围绕Sprint待办列表检查推进情况，识别阻碍；Sprint评审中，团队展示增量，相关方据此检视成果并反馈；Sprint回顾则检视团队的工作方式，可能引出对工件管理方式的改进。事件的具体流程不在本文展开，这里只需明确：工件是这些事件中被检视的对象。
承诺与工件的绑定关系
每类工件绑定一项承诺，形成“载体加判据”的结构。产品目标附着于产品待办列表，说明产品要达成的中长期状态；Sprint目标附着于Sprint待办列表，说明本轮要实现的单一目的；完成的定义附着于增量，说明什么样的成果才算完成。承诺让工件从一张清单变成有方向的清单，也使检视有明确的对照标准。
工件更新与状态变化的常见做法
工件需要随工作推进持续更新。产品待办列表会随新信息、反馈和优先级判断而增删调整；Sprint待办列表在Sprint内随进展更新剩余工作，范围调整需与产品负责人协商；增量在每个待办事项达到完成的定义时即被纳入。更新的频率和粒度由团队根据工作性质决定，关键是保持状态与实际相符。
当团队规模扩大、工件数量增多时，工件状态的同步会成为实际管理问题。ONES支持建立需求池、规划迭代，并可将需求和相关任务规划至迭代、分配负责人（依据ONES Project产品资料）；团队可通过敏捷看板管理任务状态，在每日站会中对齐迭代进度与风险（依据ONES Scrum解决方案资料）。这类工具承载的是工件的记录与呈现，工件本身的定义仍以Scrum框架为准。
工件与相关概念的区别
Scrum工件容易与几个相邻概念混淆。下面按同一口径对照，说明差异所在。
| 概念 | 与工件的关系 | 关键区别 |
|---|---|---|
| Scrum事件 | 事件使用工件，工件是事件中被检视的对象 | 事件是固定节奏的会议或时间段，工件是信息载体 |
| 承诺 | 每类工件绑定一项承诺 | 工件是内容，承诺是内容要服务的目标或质量标准 |
| 产品待办列表与Sprint待办列表 | 同属工件，层级不同 | 前者覆盖产品整体且持续演进，后者只覆盖当前Sprint且有明确时间边界 |
| 增量与发布、交付物 | 增量是工件，发布是动作 | 增量在每个事项达到完成的定义时形成，发布是把可用增量交付给用户的行为，二者不必同步发生 |
| 需求池、迭代计划 | 管理概念，可与工件对应 | 需求池是组织管理需求的容器，可承载产品待办列表；迭代计划是规划活动，产出Sprint待办列表 |
产品待办列表与Sprint待办列表的分工值得单独说明。产品待办列表是长期演进的，包含产品已知的全部候选工作，排序由产品负责人负责；Sprint待办列表是本轮Sprint的工作集合，范围在Sprint内相对稳定，由团队自行组织。两者不是简单的大小关系，而是不同时间尺度上的工作视图。
增量与发布的关系也常被误解。增量强调“可用”，即达到完成的定义；发布强调“交付”，即让用户实际获得。一个Sprint可能产生多个增量，也可能多个Sprint的增量累积后才发布一次。把增量等同于发布，会导致团队在未达到完成标准时过早宣称交付。
一个具体例子与常见误解
以下情景为演示用途，用于说明三类工件如何同时存在并相互衔接。
某小型团队负责一款内部工具。产品负责人在产品待办列表中维护了一批改进事项，并按价值排序，列表顶端对应本阶段的产品目标：让审批流程在一个季度内支持移动端提交。Sprint规划时，团队从中选取三项与移动端提交相关的事项，确定Sprint目标为“完成移动端提交的核心路径”，并把拆解后的任务写入Sprint待办列表。Sprint进行中，团队每日对照Sprint待办列表检查进展，完成一项任务就更新状态。每完成一个事项并满足完成的定义，就形成一个增量；到Sprint评审时，团队展示这些增量，相关方试用后提出反馈，反馈回到产品待办列表参与后续排序。
这个情景中，三类工件同时存在：产品待办列表提供方向和候选工作，Sprint待办列表承载本轮承诺和计划，增量是实际产出的可用成果。承诺分别附着其上，事件则提供检视和调整的节点。
常见误解纠正
- 误解一：工件等于文档模板。工件是信息载体，可以用工具记录，也可以用卡片或表格呈现。模板只是记录形式，换一种模板不改变工件的性质；反过来，填满模板也不等于工件状态清晰。
- 误解二：增量只在Sprint结束时才存在。增量在每个产品待办事项达到完成的定义时即形成，Sprint结束时只是集中检视的时间点。团队在Sprint内持续产出可用增量，评审时展示的是已经存在的成果。
- 误解三：完成的定义是团队私下约定即可。完成的定义需要与组织质量标准和组织制度保持一致，并让相关方对“完成”有共同理解。它由团队制定和使用，但不能脱离组织对质量的既有要求。
- 误解四：产品待办列表一旦确定就不应变动。产品待办列表持续演进，新增反馈、调整优先级都是正常操作。稳定的是产品目标的方向，列表内容随信息更新而调整。
把三类工件、三项承诺和事件节奏放在一起看，Scrum工件的含义就清楚了：它们是团队用来让工作可见、可检视、可调整的正式信息载体，边界之外的工具、图表和制度文档围绕它们提供支持，但不替代它们。
常见问题
团队没有严格按Scrum运作，还需要区分这三类工件吗？
如果团队只是借用部分实践，可以按实际需要选择记录方式，不必强行套用三类工件的完整结构。但只要希望用透明、检视、调整的方式推进工作，把“产品层面的候选工作”“本轮承诺的工作”“已完成的成果”分开记录，仍然有助于判断进展。区分的价值在于让不同时间尺度的工作各有载体，避免把所有信息混在一张清单里。
完成的定义由谁制定，需要写到什么程度？
完成的定义由开发团队制定并持续使用，同时要与组织的质量标准和组织制度保持一致。颗粒度上，它需要让相关方对“这项工作算不算完成”形成共同理解，通常覆盖质量要求、验证方式和必要的文档产出。写得太笼统会让增量状态难以判断，写得太细又可能增加维护负担，团队可以随工作性质调整。
产品待办列表和Sprint待办列表可以放在同一个工具视图里管理吗？
可以。两者是不同时间尺度的工作视图，工具上常表现为需求池与迭代的对应关系。ONES Project 支持建立需求池、规划迭代，并可将需求和相关任务规划至迭代、分配负责人（依据ONES Project产品资料）；ONES 也支持产品负责人按优先级将需求规划至对应迭代（依据ONES Scrum解决方案资料）。视图合并不改变两类工件的分工，产品待办列表持续演进，Sprint待办列表只覆盖当前Sprint。
一个Sprint内产生多个增量，评审时应该展示哪些？
评审的目的是检视成果并获取反馈，展示范围可以围绕Sprint目标和相关方关心的内容来确定。达到完成的定义的增量都可以纳入展示，未达到完成标准的工作则如实说明状态。展示多个增量不改变评审作为检视节点的性质，反馈回到产品待办列表参与后续排序即可。
工件状态更新频率有统一要求吗？
框架没有规定统一的更新频率，团队可根据工作性质决定。常见做法是在事项状态发生变化时同步更新，并在每日站会等固定节点对齐Sprint待办列表的推进情况。关键是让工件状态与实际相符，使检视建立在准确信息上；更新过疏会让状态失真，过密则可能增加不必要的记录负担。
