Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机会。Scrum所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个人对工件都需要有相同的理解。
一、产品待办列表（Product Blacklog)
产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。
产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的改变。产品待办列表项具有这些属性：描述、次序、估算和价值。产品待办列表项通常包括测试描述，将在“完成”时证明其完整性。
随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的列表。因为需求永不停止改变，所以产品待办列表就如一份活的工件。业务需求、市场形势或 者技术的变化都会引起产品待办列表的改变。
多个Scrum 团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用于描述下一步产品开发工作。那么这就可能需要使用能够对产品待办列表项进行分组的属性。
产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精化过程中，产品待办列表项被重新评审和修改。Scrum团队决定如何来完成精化以及何时来完成。精化的工作通常占用开发团队不超过10%的产能。然而，产品负责人或者其他人在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。
排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容和更详尽的细节信息就能做出更为准确的估算；同样，排序越低，则细节信息越少。产品待办列表项中那些即将会占用开发团队下一个Sprint大部分时间的项会被加以精化，因此，任一产品待办列表项都能够在Sprint的时间盒期限内适当地“完成”。这些能够被开发团队在一个Sprint中“完成”的产品待办列表项称为“准备就绪”，它们将作为Sprint计划会议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的精化活动来获得。 开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。
好的产品Blacklog做到DEEP：
1、粗细适宜的（Detailed appropriately）：待办事项列表顶端的百分之十可能包含非常小且分析得很详细的事项，而其他的百分之九十则不是那么具体。
2、估算过的（Estimated）：团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术风险估算。
3、涌现式的（Emergent）：为了响应学习和变化，要定期梳理产品待办事项列表。产品负责人会不断地更新产品待办事项列表，以反映客户需求的变化、新想法或见解、竞争而导致的变化、出现的技术障碍等。
4、排好优先级的（Prioritized）：在产品待办事项列表顶端的事项具有最高优先级，或者是从1开始顺序排列。
监控目标实现的进度
在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个Sprint评审会议中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前Sprint评审会议时的剩余工作量，来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关者都是透明的。各种不同趋势走向的实践已经被使用在预测进度方面，例如，燃尽图（burn-downs）、燃烧图（burn-ups）或者累积流图（cumulative flows）。这些工具都被证实是有用的。然而，它们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法预知的。只有已经发生的事情才能用来做前瞻性的决策。
二、Sprint待办列表（Sprint Backlog）
Sprint 待办列表是一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划。
Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。
Sprint 产品待办列表将开发团队用来达成Sprint目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在先前回顾会议中确定下来的高优先级过程改进。Sprint产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日Scrum站会中清晰地看到。开发团队在Sprint期间修改Sprint待办列表，使得Sprint待办列表在Sprint期间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达成Sprint目标所必需的工作时。 当新工作出现时，开发团队需要将其加入到Sprint待办列表中去。随着工作的执行或完成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。
在 Sprint 期间，只有开发团队可以改变Sprint待办列表。Sprint待办列表是高度可见的，是对开发团队计划在当前Sprint内工作完成情况的实时反映，该列表由开发团队全权负责。
Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:
1、随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中
2、程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作。 Product Owner也许会和Scrum team一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。
监控 Sprint 进度
在Sprint的任何时间点都可以计算Sprint待办列表中所有剩余工作的总和。开发团队至少在每日Scrum站会时跟踪剩余的工作量，预测达成Sprint目标的可能性。通过在Sprint中不断跟踪剩余的工作量，开发团队可以管理自己的进度。
Scrum 不考虑已经花在Sprint待办事项列表上的工作时间。我们只关心剩余工作和日期这两个变量。
通过燃尽图（Burn-down Chart)跟进进展
Sprint燃尽图（Sprint Burn-down Chart)显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。
在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能略微呈上升趋势。
发布燃尽图（Release Burn-down Chart）
在Scrum项目中，团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期，以Sprint为单位， Y轴代表的是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。
三、产品增量（Product Increment）
增量是一个Sprint完成的所有产品待办列表项的总和，以及之前所有Sprint所产生的增量的价值总和。在Sprint的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。增量是在Sprint结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。
工件透明
Scrum 依赖于透明。优化价值和控制风险的决定都是基于所获知的工件状态。当工件的状态是完全透明时，这些做出的决定才有一个坚实的基础；当工件的状态是不完全透明时，这些做出的决定就会有瑕疵，而价值也可能因此遭受损失，同时风险也可能会因此而增加。
Scrum Master 必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都是完全透明的。有些实践就是为应对不完全透明的状态而生的，Scrum Master 必须帮助每个人，让他们能够在遇到不透明的情况下采取最合适的实践。Scrum Master 能够通过检视工件、嗅探模式、倾听周围的声音以及观察预期和实际结果的差异来发现不完全透明。
Scrum Master 的职责就是和Scrum团队以及组织一起合作增加工件的透明化。这一工作通常包括学习、说服和改变。 透明化不会在一夜之间发生，但是这是一条必经之路。
“完成”的定义
当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什么有相同的理解以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。
这一定义也同时被用来指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增量。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。 如果增量“完成”的定义不是开发组织的惯例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起开发，那么所有 Scrum 团队中的开发团队必须一起参与制定“完成”的定义。
每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。
随着团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量。当使用新定义时，在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统都应该对其上面开发的工作有“完成”的定义。