Scrum工件是Scrum框架中承载产品价值、透明度和检视依据的三类核心对象：产品待办列表、Sprint待办列表和增量。它们分别回答“要做什么、本轮承诺做什么、已经完成了什么”，并通过承诺与完成定义形成可检视的透明状态。本文围绕三类工件的定义、边界、运转机制及常见误解展开，帮助读者把工件与事件、角色和可视化工具区分开。
要点总览（TL;DR）
- Scrum工件只有三类：产品待办列表回答“产品要做什么”，Sprint待办列表回答“本轮承诺做什么、怎么做”，增量回答“已经完成了什么”。
- 三类工件各自对应一个承诺：产品目标、Sprint目标、完成定义；承诺是工件自带的属性，完成定义不构成第四类工件。
- 燃尽图、看板视图、会议记录、甘特图属于可视化或辅助材料，由工件数据派生，不属于框架规定的核心工件。
- 工件提供透明度，事件提供检视与调整的节奏；工件长期不更新，检视就失去可靠依据。
- 增量指满足完成定义的可用成果，可以叠加交付，与是否对外发布是两件事。
Scrum工件包括哪三类
Scrum只规定三类工件。理解这一点，先要抓住每类工件各自回答的问题，再记住它由谁负责、以什么形态存在。三类工件并非并列的文档清单，而是从长期价值到本轮承诺、再到可用成果的一条递进链条。
产品待办列表（Product Backlog）是一份有序的价值需求清单，回答“产品要做什么”。它由产品负责人管理，条目可以是需求、改进、缺陷修复或实验想法，排序体现价值、风险和依赖的综合判断。产品待办列表始终处于演进状态，顶部条目通常更细、更清晰，越靠下越粗略，随着理解加深不断被细化、重排和删减。
Sprint待办列表（Sprint Backlog）由本轮Sprint选中的产品待办条目加上执行计划组成，回答“本轮承诺做什么、打算怎么做”。它是开发者在Sprint期间的工作视图，随进展每日更新；当发现原计划不可行时，开发者与产品负责人协商调整范围，而不是固守一份初始清单。
增量（Increment）是满足完成定义的可用成果，回答“已经完成了什么”。每个Sprint结束时都应产生一个增量，增量可以叠加在前一个增量之上交付，因此它强调的是“可用且符合完成定义”，而非“已经对外发布”。
| 工件 | 一句话定义 | 回答的问题 | 主要管理者 | 对应承诺 |
|---|---|---|---|---|
| 产品待办列表 | 有序的价值需求清单 | 产品要做什么 | 产品负责人 | 产品目标 |
| Sprint待办列表 | 本轮选中的条目加执行计划 | 本轮承诺做什么、怎么做 | 开发者 | Sprint目标 |
| 增量 | 满足完成定义的可用成果 | 已经完成了什么 | 开发者 | 完成定义 |
这张表把三类工件的定义、负责人和承诺放在同一口径下对照，便于在讨论中快速确认“说的是哪一类工件”。需要留意的是，承诺是工件自带的属性，不是额外的第四类对象，这一点在下一节边界说明中会进一步展开。
工件的边界：哪些内容不属于Scrum工件
把工件与相邻概念分开，是准确使用这一术语的前提。日常团队里出现的很多产物都有价值，但它们不因此成为Scrum框架规定的工件。判断标准可以简化为一句：它是否承载产品价值、并作为透明与检视的对象被框架明确要求。
首先区分工件与事件。Sprint规划、每日站会、Sprint评审和Sprint回顾是Scrum的四个正式事件，它们是有固定目的和时限的“场合”，用来检视和调整工件。事件本身不承载需求或成果，因此不属于工件；工件是事件中被查看、被讨论、被更新的对象。
其次区分工件与可视化工具。燃尽图、看板视图、累积流图等属于度量和可视化手段，帮助团队观察剩余工作与流动情况。它们由工件数据派生，随工件变化而变化，但框架并未把它们规定为核心工件。团队可以自由选用或替换这些视图，而不影响三类工件的成立。
再次区分工件与承诺。产品目标、Sprint目标和完成定义分别是三类工件对应的承诺，它们为工件提供方向和“做到什么程度才算完成”的判据。完成定义是增量的承诺属性，附着在增量之上发挥作用，不应被当作独立的第四类工件；把它单列出来，容易让人误以为Scrum有四类工件。
最后，会议记录、甘特图、需求规格文档、测试报告等团队自制的管理产物，属于支持协作的材料。它们可以辅助工件管理，但需要明确其定位是辅助材料，避免在讨论中与核心工件混为一谈，导致“工件很多、重点不清”的沟通成本。
工件如何运转：承诺、透明与检视
三类工件之所以能支撑Scrum的运转，靠的是“承诺—透明—检视”这条闭环。每个工件都对应一个承诺，承诺让工件有了判断进展的标尺；工件本身提供透明度，让团队和相关方看到真实状态；事件则基于这些透明状态进行检视，并做出调整。
承诺与工件的对应关系是固定的：产品待办列表对应产品目标，描述产品要达成的长期方向，为条目排序提供依据；Sprint待办列表对应Sprint目标，说明本轮Sprint要实现的单一目的，帮助开发者在范围内做取舍；增量对应完成定义，明确“完成”的质量标准，使“可用成果”有可核验的口径。
透明度来自工件的持续更新。产品待办列表在发现新信息时被细化与重排；Sprint待办列表在Sprint期间随任务进展每日更新，反映真实剩余工作；增量在每个Sprint结束时形成，并叠加到已有成果之上。工件若长期不更新，透明度就会下降，检视也就失去可靠依据。
检视与调整发生在事件中，但对象始终是工件。Sprint规划检视产品待办列表并形成Sprint待办列表；每日站会检视Sprint待办列表的进展并调整当日计划；Sprint评审检视增量并收集反馈，进而影响产品待办列表；Sprint回顾检视团队的工作方式，产出改进行动。可以看到，事件是节奏，工件是内容，两者配合才构成完整的运转机制。
当团队把工件放到协作工具中承载时，这条闭环会更容易被看见。以ONES为例，团队可以用工单收集和整理反馈，处理工单并转化为需求，整理出产品待办列表，并按实际场景自定义工作流；产品负责人可以按优先级把需求规划至对应迭代，在迭代计划会议上与团队共同评审。迭代过程中，成员围绕要完成的需求拆解任务，通过敏捷看板管理任务状态，并在每日站会中借助看板对齐进度与风险。这里需要分清：看板和燃尽图是可视化与度量工具，帮助观察工件状态，三类工件本身仍按Scrum的定义理解。对于完成定义、需求背景等需要沉淀的内容，ONES Wiki支持文档关联任务，并可插入工作项列表，让文档与任务衔接起来。
工件与事件、角色的区别
工件、事件、角色是Scrum中三个不同层面的概念，混用会导致职责和节奏的讨论失焦。一个简单的区分方式是：角色是“人”，事件是“时间”，工件是“对象”。
角色是承担职责的人。产品负责人对产品待办列表的内容、排序和价值最大化负责；Scrum Master负责推动Scrum的正确理解和实践，帮助团队排除障碍；开发者负责在每个Sprint中交付满足完成定义的增量，并管理Sprint待办列表。角色回答的是“谁来做、谁负责”。
事件是固定节奏的会议或时段，包括Sprint本身以及Sprint规划、每日站会、Sprint评审和Sprint回顾。它们提供规律性的检视与调整机会，回答的是“什么时候做、在什么场合检视”。事件有明确的目的和时限，但不产出需求条目或成果本身。
工件是被管理的对象与产出，回答的是“管理什么、交付什么”。三者对照如下：
| 概念类别 | 回答的问题 | 典型内容 | 判断要点 |
|---|---|---|---|
| 角色 | 谁来做、谁负责 | 产品负责人、Scrum Master、开发者 | 指向承担职责的人 |
| 事件 | 什么时候做、在哪检视 | Sprint、Sprint规划、每日站会、评审、回顾 | 指向有目的和时限的场合 |
| 工件 | 管理什么、交付什么 | 产品待办列表、Sprint待办列表、增量 | 指向承载价值与透明度的对象 |
用这张表检查日常表述，可以避免常见混淆。例如“产品负责人参加每日站会”描述的是角色与事件的关系；“每日站会更新Sprint待办列表”描述的是事件与工件的关系；而“产品待办列表由产品负责人排序”描述的是角色与工件的关系。把关系说清楚，讨论才不会把“谁负责”误当成“什么是工件”。
一个例子与常见误解
下面用一个演示情景说明三类工件在一个Sprint中的变化。某团队正在开发一个订单管理功能，Sprint周期为两周，以下情节为示意，用于解释工件关系，不代表真实项目数据。
Sprint开始前，产品负责人在产品待办列表中按价值排序了若干条目，顶部包括“订单列表分页”“订单状态筛选”“导出订单”等，并标注了粗略估算。Sprint规划会上，团队选中“订单列表分页”和“订单状态筛选”两项，围绕Sprint目标“让运营人员能快速定位目标订单”拆解出前端分页组件、接口改造、筛选条件联调等任务，形成Sprint待办列表。此时，产品待办列表回答“产品要做什么”，Sprint待办列表回答“这两周承诺做什么、怎么做”。
Sprint进行中，团队发现筛选条件的接口需要额外兼容旧数据，Sprint待办列表随之增加任务并调整顺序；产品负责人则在产品待办列表顶部补充了一条来自客服反馈的“订单备注显示”需求，并重新排序。每日站会上，团队查看Sprint待办列表的剩余任务和看板状态，决定是否缩小范围以确保Sprint目标达成。
Sprint结束时，两项需求都满足完成定义，形成可用的增量，并叠加到上一轮已完成的订单查询能力之上。评审会上，相关方检视增量并提出反馈，这些反馈回到产品待办列表，成为下一轮排序的输入。整个过程中，工件在持续更新，事件按节奏发生，角色各司其职。
围绕这个例子，有两类误解值得澄清。
误解一：把用户故事等同于产品待办列表的全部内容。用户故事是描述需求的常用写法，产品待办列表的条目可以采用用户故事，也可以采用缺陷、技术改进、实验等形式。产品待办列表的关键特征是有序和持续演进，而非条目采用某种固定模板。把两者画等号，容易忽略缺陷修复和技术债等同样需要排序的条目。
误解二：增量等于已上线功能。增量是满足完成定义的可用成果，它可以在Sprint结束时形成并叠加，是否对外发布由产品决策和发布安排决定。把增量等同于已上线功能，会导致团队把“发布”当作“完成”的唯一标准，从而在完成定义的讨论中偏离质量口径。区分“形成增量”和“发布增量”，有助于把工件状态与发布节奏分开管理。
理解这三类工件及其边界后，团队在讨论需求、承诺和成果时就有了共同语言：产品待办列表管方向和排序，Sprint待办列表管本轮执行，增量管可用成果，承诺与完成定义则为它们提供判断标准。
常见问题
完成定义需要单独作为一个Scrum工件来管理吗？
不需要。完成定义是增量对应的承诺，附着在增量之上，用来判断成果是否达到可用的质量标准。把它单列为第四类工件，会让人误以为Scrum有四类工件。实践中可以把完成定义写成团队共同确认的条目，在Sprint规划和评审时对照检查，但它的身份始终是承诺属性，而非独立工件。
产品待办列表里的条目必须写成用户故事吗？
不必须。产品待办列表的关键特征是有序和持续演进，条目可以是用户故事，也可以是缺陷修复、技术改进、实验想法等形式。采用统一模板有助于沟通，但模板不是工件的成立条件。团队更需要关注的是条目是否被合理排序、顶部条目是否足够清晰到可以进入Sprint。
Sprint进行中发现原计划不可行，Sprint待办列表可以改吗？
可以调整，但要守住Sprint目标。Sprint待办列表是开发者在Sprint期间的工作视图，随进展更新；当发现范围不可行时，开发者与产品负责人协商调整范围，而不是固守初始清单。判断调整是否合理的依据是Sprint目标能否达成，以及调整后的工作是否仍指向同一个目的。
增量已经形成但暂不发布，还能算完成吗？
可以。增量是满足完成定义的可用成果，每个Sprint结束时形成并叠加到已有成果之上；是否对外发布由产品决策和发布安排决定。把“形成增量”和“发布增量”分开看，团队才能在完成定义的讨论中聚焦质量口径，而不是把上线当作完成的唯一标准。
团队用工具管理工件时，需要额外注意什么？
关键是分清工具视图与工件本身。看板、燃尽图帮助观察工件状态，属于可视化与度量手段；产品待办列表、Sprint待办列表和增量仍按Scrum的定义理解。以ONES为例，团队可以用工单收集反馈并转化为需求，整理出产品待办列表，按优先级规划至迭代，通过敏捷看板管理任务状态；完成定义、需求背景等内容可在ONES Wiki中沉淀并与任务关联。工具承载的是工件的状态流转，不改变工件的定义边界。
