在 Scrum 的实施过程中，Scrum 工件（Artifacts）为 Scrum 团队及产品相关方提供关键信息，使其随时了解开发工作的内容、计划、进度和成果。Scrum 框架中最为不可或缺的工件是产品待办列表、Sprint 待办列表、增量与完成定义，其他工件还包括产品愿景、用户故事、Sprint 目标、燃尽图，等等。
产品待办列表是为实现产品愿景而需要完成的全部工作的有序列表，这些工作包括新的用户需求、对现有功能或设计的更改、待修复的缺陷、基础架构调整，以及其它对交付成果有意义的事情，或在前面 Sprint 评审会上被提出的实践改进方案等。产品负责人负责管理产品待办列表的内容、可用性和排序，确保产品待办列表是开发团队讨论 Sprint 目标和计划的唯一信息来源。
高质量的产品待办列表符合“DEEP”的原则，即：
-
Detailed Appropriately，详略得当的 — 要对在接下来的 Sprint 中完成的产品待办事项有着足够详细、能让开发团队充分理解的呈现，包括文字描述、原型图、参考资料等，而更长期的则允许相对粗略。开发团队决定产品待办事项的表述格式，并准备好安排开发的标准，最常见的是写成“作为【角色】, 我想要【功能】, 以便于【目的、价值或收益】”这样的“用户故事（User Story）”，并尽可能考虑周全用户的身份、特征、故事所处的上下文、用户实现故事目的的过程步骤和最终状态，以及是否能在一个 Sprint 内完成交付，并制定检测完成与否的方式、标准。
-
Estimated，估算的 — 估算，即预估开发一项产品待办事项使其达到“完成”定义所需要的复杂度（故事点）或工作量（人天），Scrum 团队借助估算就产品开发进度、发布节点、Sprint 目标和计划、具体开发思路等达成共识。当产品待办事项的介绍包含更多细节，也就意味着开发团队能对其做出更为精确的估算，从而结合自身交付能力，合理安排接下来的 Sprint 。但非近期交付的待办事项并非完全不需要估算，因为产品负责人需要知道所有待办事项和产品阶段性目标之间的关系，通常他会和开发团队依据此前经验，先为中长期的待办事项做出大概的预估，将重要事项精化，放置到靠前的排位，从而使估算结果更为可靠。另一方面，如果某个待办事项不好估算，则说明还没达到准备开发的标准。
-
Emergent，涌现的 — 产品待办列表不是静止的而是动态的，需要被持续更新以反映需要做些什么来保持产品的适用性、竞争力、使用率。用户需求、市场形势或者技术的变化都会引起产品待办列表的改变，确切地说，产品待办列表中的事项会被增加、移除、重写、拆分或重新排序。因此，放进产品待办列表上的事项并非 Scrum 团队必须完成的承诺，而是一种提醒，提醒 Scrum 团队需要将它们打磨得足够清晰、明确才能放入 Sprint ，或者删去那些被认为无法为预期结果带来贡献的。当然产品待办事项一旦被放入 Sprint，就要尽量避免更改，否则会影响开发团队的焦点和士气。
-
Prioritized，有序的 — 产品待办列表中的事项按实现价值的优先级呈现唯一顺序，以便开发团队根据该顺序制定 Sprint 计划。产品负责人在给产品待办事项排序时，会考虑价值、风险、亟需程度、相关方偏好、投入产出比、技术实现次序等因素，定义一个综合性的评判规则。排序越靠前的产品待办事项通常比排序靠后有着更清晰的表述呈现和更为可靠的估算。开发团队始终优先完成最靠前的事项，以确保当前 Sprint 的交付增量带来最优化的商业价值。
产品负责人在每个 Sprint 评审会中都会跟踪产品待办列表中剩余事项的总量，利用燃尽图（Burn-downs）或者累积流量图（Cumulative Flows）等工具衡量开发团队的交付速率（Velocity），以预判在未来期望的时间点达成产品阶段目标的进度，做出及时的调整和多方沟通。更多关于产品待办列表的详情可以查看博客文章：《Product Backlog：终极任务清单》。
Sprint 待办列表是产品待办列表的一个子集，即为实现当前 Sprint 的目标，从产品待办列表中选出的一组产品待办事项，以及为完成这些事项，开发团队需要执行的任务和工作计划。开发团队对 Sprint 待办列表全权负责，同时 Sprint 待办列表为开发团队提供了短期的清晰焦点，可以保护团队不受产品负责人持续精化产品待办列表的影响。
在 Sprint 计划会上，Scrum 团队共同将 Sprint 待办列表制定出来。之后，开发人员从拥有足够细节的 Sprint 计划中领取自己想要负责的任务，及时更新任务状态，团队利用每日站会和燃尽图等工具了解当前 Sprint 的剩余工作量，跟进和管理进度。在 Sprint 的尾声，产品负责人向产品相关方介绍当前 Sprint 待办列表的完成情况，开发团队逐一演示确定完成的产品增量。
在 Sprint 期间，只有开发团队可以改变 Sprint 待办列表，相关操作包括：
- 围绕 Sprint 目标和开发进度，添加或删除任务，调整开发计划；
- 移除计划中的某个失去开发意义的产品待办事项；
- 如果不得不对已经启动的 Sprint 增加计划外的产品待办事项，则需要取消当前 Sprint 待办列表中估值之和与之相同或较之更大的产品待办事项，并将这些临时取消的事项放回至产品待办列表，由产品负责人重新排序；
- 截止 Sprint 时间期限，需要将未达到“完成”定义的产品待办事项放回产品待办列表重新评估。
每个 Sprint 计划的产品待办事项都是“潜在可交付的”，只有达到 Scrum 团队规定的“完成”定义（Definition of Done），又称 DOD 原则，才是终端用户可用的、有真正价值的产品“增量”（Increment）。增量即一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Scrum 的这一理念体现了敏捷软件开发最基本的原则：通过持续不断地及早交付有价值的软件使客户满意；可工作的软件是进度的首要度量标准。
在启动第一个 Sprint 之前，Scrum 团队需要从整体上就“完成”定义的基本结构和标准达成共识，以便在每个 Sprint 的最后合理地评判出哪些产品待办事项构成了新的产品增量。换句话说，当产品待办事项或增量被描述为“完成”时，每名团队成员都必须对“‘完成’意味着什么”有着相同的理解。在此基础上，每个产品待办事项一旦被放入 Sprint ，都应该包含一组由更为具体的完成和检验标准组成的核对清单，并对全员透明。这样做的目的是：
- 指导开发团队在 Sprint 计划会上选择适量的产品待办事项和讨论实现思路；
- 在团队内部就质量和完整性建立共识；
- 限制返工的成本；
- 减少开发团队与产品所有者、产品相关方之间的误解。
诚然，每个 Sprint 的“完成定义”与“潜在可交付”越接近越好。不过需要注意的是，随着 Scrum 团队的成熟，工作流程和方式的改进，“完成”定义的要求也会更为严格。如果此前 Scrum 团队对“完成”的要求较低，那前面的 Sprint 遗留和累积下来一些“已完成”的工作一旦影响到产品发布，Scrum 团队就需要安排一个额外的 Sprint 来处理它们。