Scrum 的主要工件是产品待办列表（ Product backlog）、迭代待办事项清单（Sprint backlog ）和增量（Increments），除此以外还有一些扩展工件，如燃尽图等。这些工件是在软件计划、开发、跟踪和迭代（Sprint）过程中积累总结的 Scrum 经验，用以帮助更好的构建软件。
下面我们将来为大家介绍 Scrum 三大主要工件，它们在产品开发过程中的作用，以及如何建立。
一、什么是敏捷 Scrum工件
Scrum 工件是敏捷团队和利益相关者用来描述正在开发的产品、生产该产品涉及的工作内容、及在项目期间的工作内容。这些工件提供了最基础开发内容，能够让团队了解到每一次迭代工作内容和最终要实现的产品效果。它们是每个Scrum团队开展工作的基础，因为它们能够帮助团队建立以及改进自己的Scrum文化。
这些工件应该是每个 Scrum 团队的基本工具，因为他们不仅为团队提供了数据依据，使团队能够深入了解迭代的情况，同时也帮助团队建立起公开透明、持续改进等核心文化。
工件是在 Scrum 迭代过程中创建的用来：
- 计划工作和目标；
- 创建、分解任务以实现这些目标；
- 根据需求的依赖性和优先级，将任务安排到每个迭代阶段；
- 执行开发任务；
- 评审和验证交付物，以便与目标进行比较；
- 持续改进，重复这一流程，重复有效的经验。
二、Scrum 的主要工件及其作用
敏捷 Scrum 的主要工件 Product backlog、Sprint backlog 和增量。
1.Product backlog 的构建方法
Product backlog 是一个产品所有功能、技术、缺陷等需求的列表，它是由客户支持、竞争对手分析、市场调研需求和一般商业分析等渠道汇总产生。Product backlog 是一个“动态”的，跨团队的工件，因为它需要根据各方的业务需要、市场环境和技术的变化及时进行调整。
那么 Product Owner 怎么对 Product backlog 负责呢？
- 首先，他权衡各个需求后排列出需求的优先顺序；
- 其次，负责向团队清楚地表达 Product backlog；
- 然后，他要确保 Product backlog 是可见的、透明的，所有人都清楚下一步该做什么工作；
- 最后，在创建 Product backlog 的同时，还需要包括测试描述，这些测试描述将在“完成”时验证产品的完整性。
同时 Product Owner 也会听取团队对列表的建议，适当的进行调整，例如在描述需求后如果开发团队表示工作太多或太少，可以与 Product Owner 重新协商，开发团队也可以邀请技术专家参加。Product backlog 代表的是各方的业务需求，当发生变更时，或利益相关者如果想要改变 Product backlog 的优先级，必须向 Product Owner 提出请求。
Product backlog 的内容和顺序中是透明可见的，没有人可以强迫开发团队做列表范围以外的需求工作。
2.Sprint backlog 的构建方法
Sprint backlog （迭代待办事项清单）是一个迭代计划周期内要完成的待办事项集合，它在迭代计划中由开发团队一起协商产生，用以计划下一个周期的交付目标，并详细说明交付这些功能所需的工作量预测。
迭代待办事项清单中的任务来源于 Product backlog，但团队并不是简单将 Product backlog 中的人挪到迭代待办事项清单，而是需要将那些史诗、特性级别的需求分解成更小的、可估算、可实现的任务，并加以完善。
举一个例子，如 “建立购物车页面”的需求，它是一个大的特性，可以拆解成许多设计、开发子任务。Product backlog 中可能包含史诗、特性、用户故事等不同级别的任务，而迭代待办事项清单中，则只有如“创建购物车视觉模型”、“购物车支持一键清空”等可估算、可实现的用户故事/任务。
迭代待办事项清单在迭代计划会议中产生，一旦迭代计划会结束，产品负责人就不能再修改迭代待办事项清单的故事清单了。这是 Scrum 中业务方和开发团队之间的基本协议，每次 Sprint 开始前，业务方都可以改变方向，然而 Sprint 开始以后，团队则会专注于他们所承诺完成的故事。改变这个已承诺的故事清单只有一个方式，就是由干这个活儿的团队成员提出变更请求。
也许团队发现他们能比最初设想的做更多的活，也或许他们无法交付所有已经承诺的故事。遇到这种情况，产品负责人将和团队一起修改 Sprint 列表中的故事清单。
3、产品增量是什么？
产品增量是指在一个迭代周期内需要完成的产品待办任务所开发出来的交付物，它还包括之前所有迭代周期的增量。每一个 Sprint 都会产生一个增量，这是在计划阶段就确定好的，无论团队最后是否决定发布，都会有一个增量，并且该增量一定处在可用的状态。产品增量无论是对于CI/CD、版本跟踪还是必要时的版本回滚都是是非常有价值的。
TIPS：将团队的工作内容与产品待办事项列表中的任务保持一致是十分有益的。举个例子：如果我们为每个待办事项都创建一个分支和构建，并将版本控制和 CI/CD 工具都集成到 Scrum 项目管理软件，那么团队就可以更统一、便捷地了解工作的进展。他们也可以随时了解到哪些项目正在被部署或者发布。同时，团队还可以反向查看提交，然后把它们与 Scrum 增量绑定，以查看该代码的历史和未来的规划。
4.Scrum 扩展工件有哪些？
除了前面讨论的 Scrum 指南中提及的“官方”工件之外，还有一些扩展工件。这些虽然不是出自 Scrum 指南，但这些扩展的工件也为 Scrum 开发流程的管理增加了额外的价值和洞察力。
燃尽图
迭代燃尽图（或燃尽图）并非官方的 Scrum 工件，但许多团队在迭代期间会使用它来沟通和跟踪迭代目标的进度。燃尽图是显示迭代期间任务完成进度的图表，在帮助衡量团队执行速度方面非常有价值，比如团队能够凭借燃尽图了解团队是否将会按时完成计划，或者需要重新确定迭代任务的优先级。
除此以外，团队还可以在迭代计划会期间，通过查看之前的燃尽图，以判断他们在即将到来的迭代需要完成多少任务。而在迭代评审会期间，团队可以重新查看燃尽图，看看他们在哪里达到或没有达到预期。随着时间的推移，燃尽图可以帮助团队在更好地改进他们在计划阶段的预估。
“完成”的定义（DoD）
团队对 “完成 “有一个明确的定义是很重要的。这个定义可以算是另一种类型的工件，它应该被记录和分享。比如，一个开发团队对任务”完成 “的定义是：当代码被自动测试覆盖，符合规范，并被部署到生产环境。而一个没有明确定义 “完成 “的团队会发现，自己在迭代评审（Sprint review）时经常会问 “这是完成了吗？”。
对“完成”进行定义还有助于定义增量的边界，增量应该以完整的可用的形式交付，与之前的增量是相辅相成的。同时，“完成”也定义了任务完成的时间。
工件透明度
Scrum 工件是帮助团队更有效运作敏捷的强大辅助工具，因此，所有的团队成员都应该能访问和了解工件。Product Ower（产品负责人）和Scrum Master（敏捷教练）需要定期与开发团队检查和讨论以上这些工件，这将有助于团队对自身的效率有一个持续的关注，并实现持续改进。
小结
敏捷 Scrum工件是非常有价值的，但这并不代表工件是敏捷 Scrum工作流程中的硬性依赖。一个团队可以在不借助任何辅助的情况下引入和实行敏捷开发，也可以在一开始就使用一个内置有敏捷 Scrum工件的敏捷项目管理工具，像 PingCode 这样，可以让团队毫不费力地生成燃尽图、管理 Product backlog 和增量。
