规模化Scrum术语

原则：透明

流程和工作必须对执行工作的人员以及接收工作的人员可见。对于 Scrum，重要决策基于其三个正式工件的感知状态。透明度低的工件可能会导致价值降低和风险增加的决策

原则：检查

必须经常、认真地检查 Scrum 工件和实现商定目标的进度，以发现潜在的不良差异或问题。为了帮助检查，Scrum 以五个事件的形式提供节奏

原则：调整

如果过程的任何方面偏离可接受的限度或最终的产品不可接受，则必须尽快进行调整，以尽量减少进一步的偏差

团队：开发人员

Scrum 团队中致力于在每个 Sprint 中创建可用增量的任何方面的人员，终对以下方面负责：

• 1. 为冲刺（Sprint Backlog）制定计划
• 2. 遵守“完成的定义”
• 3. 每天调整他们的计划以实现 Sprint 目标
• 4. 作为专业人士相互承担责任

团队：Product Owner

负责最大化 Scrum 团队工作所产生的产品价值。同时负责有效的产品待办事项管理，其中包括：

• 1. 制定并明确传达产品目标
• 2. 创建并清晰传达产品待办事项列表项
• 3. 维护产品待办列表的优先级
• 4. 确保产品待办事项列表透明、可见且易于理解

团队：Scrum Master

负责按照 Scrum 指南中的定义建立 Scrum，并通过帮助 Scrum 团队和组织内的每个人了解 Scrum 理论和实践来做到这一点

活动：Sprint

Sprint 是 Scrum 的心跳，在这里想法转化为价值。实现产品目标所需的所有工作，包括冲刺计划、每日 Scrums、冲刺评审和冲刺回顾，都在Sprint内进行

活动：Sprint Planning

Sprint 计划通过布置 Sprint 中要执行的工作来启动 Sprint。Sprint 计划涉及以下主题：

• 1. 为什么这个 Sprint 有价值
• 2. 这个 Sprint 可以做什么
• 3. 所选的工作将如何完成

活动：Daily Scrum

Daily Scrum 的目的是检查 Sprint 目标的进展情况，并根据需要调整 Sprint Backlog，调整即将到来的计划工作

活动：Sprint Review

Sprint 评审的目的是检查 Sprint 的结果并确定未来的调整。Scrum 团队向主要利益相关者展示他们的工作结果，并讨论产品目标的进展情况

活动：Sprint Retrospective

Sprint 回顾的目的是规划提高质量和有效性的方法。Scrum 团队检查上一个 Sprint 在个人、交互、流程、工具及其完成定义方面的进展情况，确定最有帮助的改进

工件：Product Backlog

产品待办事项列表是一个有序（优先级排序）的列表，列出了改进产品所需的内容。它是 Scrum 团队承担工作的唯一来源

工件：Sprint Backlog

Sprint Backlog 是开发人员制定，由 Sprint 目标（为什么）、为 Sprint 选择的一组 Product Backlog 项目（做什么）以及交付增量的可行计划（如何做）组成

工件：Increment

增量是实现产品目标的具体介质。每个增量都是所有先前增量的补充，并经过彻底验证，确保所有增量协同工作。除非工作符合完成的定义，否则不能将其视为增量的一部分

团队：Product Owner

LeSS 中的产品负责人角色在概念上与单团队 Scrum 中的产品负责人角色相同。然而，重点转向确保产品的最大投资回报 (ROI)。此外，鼓励并帮助团队与真正的客户进行直接对话以澄清问题。PO只是充当联络人，而不是中间人

团队：Area Product Owner

区域产品负责人 (APO) 担任该需求区域团队的产品负责人。区域产品负责人的工作与产品负责人相同，但视角更有限。APO 和 PO 共同组成一个团队 — 产品负责人团队。该团队做出产品范围的优先级决策，但 PO 始终拥有最终决定权

团队：Scrum Master

LeSS 特别强调，LeSS 中的 Scrum Master 是一个专注的全职角色。群体越大，就越难看到整体。Scrum Master 的最主要职责是帮助人们超越个人视角，看到更大的生产系统——产品组交互、延迟、原因和潜力，同时提醒大家要以整体产品为中心

活动：Daily Scrum

LeSS 中的每日 Scrum 是按团队完成的，与单团队 Scrum 没有什么不同。为了保证团队间的协调，可以让其他团队的人员加入观察。根据每日 Scrum 期间了解到的信息，不同团队成员可能决定在每日 Scrum 之外进行后续讨论

活动：Sprint Planning

冲刺计划由两部分组成，第一部分是所有团队一起召开的会议，决定哪个团队将处理哪些项目。第二部分是由每个团队单独完成，每个团队创建自己在冲刺期间的计划以“完成”项目

活动：Sprint Retrospective

在冲刺结束时，所有团队都有各自的回顾，这与单团队 Scrum 回顾是一样的。 LeSS 中增加了的一个新会议：总体回顾，其目的是讨论组织内的跨团队、组织和系统问题，参加者是产品负责人、Scrum Master、团队代表和管理者

活动：Product Backlog Refinement

每个 Sprint 中都需要进行持续的产品待办事项细化 (PBR)，以细化项目，为未来的 Sprint 做好准备。PBR 的关键活动是 (1) 拆分大项目，(2) 澄清项目直至准备好实施，(3) 估计规模、“价值”、风险。PBR包含多团队PBR和单团队PBR两个部分

工件：Product Backlog

多个团队根据单个产品待办事项列表构建单个产品，该产品待办列表定义了要在产品上完成的所有项目/工作。团队并没有自己的产品待办事项列表

工件：Area Product Backlog

产品负责人(PO) 将每个产品待办事项列表项分组到对应的一个需求类别（也称为需求区域）下，按照需求类别的方式 PO 可以生成整个产品待办事项列表的不同视图（称为“区域待办事项列表”）。区域待办事项列表由专门研究部分产品的区域产品负责人从客户的角度确定优先级

工件：Increment

每个 Sprint 的输出称为“潜在可交付产品增量”。所有团队的工作必须在每个 Sprint 结束之前进行整合——整合必须在 Sprint 期间完成。因为是多团队协作，为了降低整合风险， Sprint 期间内持续集成是推荐的

Scrum of Scrums (SoS)

运作就像一个 Scrum 团队，用 Scrum 责任、事件和工件的扩展版本来满足团队流程组件的要求。组成 Scrum of Scrums 的团队负责在每个 Sprint 结束时完全集成一组可能交付的产品增量

• 更多
• 50+团队规模化Scrum的组织架构

SoSoS

根据实施的规模，可能需要多个 Scrum of Scrums 来交付复杂的产品。在这种情况下，可以从多个 Scrums of Scrums 中创建一个 Scrum of Scrums of Scrums (SoSoS)。其中每一个都将具有每个 Scrum of Scrum 的角色、工件和事件的缩放版本。SoSoS 与 Scrum of Scrums 的接口方式与 Scrum of Scrums 与单个 Scrum 团队的接口方式完全相同，从而实现线性可扩展性

Scaled Daily Scrum (SDS)

规模化环境中，Scrum of Scrums 需要了解集体进展并对参与团队提出的障碍做出响应；因此，每个团队至少有一名代表参加 Scaled Daily Scrum (SDS)。任何参赛团队的个人或人数均可根据需要参加

Scaled Retrospective

每个 Sprint 中的 Scrum 都会举办规模化的 Sprint 回顾会，每个团队的 Scrum Master 都会聚在一起讨论为推动持续改进而进行的实验及其结果。此外，他们应该讨论下一轮实验以及如何在整个团队或其他团队中利用成功的改进

SoSM

Scrum of Scrums 的 Scrum Master 被称为 Scrum of Scrums Master（SoSM）。SoSM是真正的领导者，通过了解跨团队依赖关系（包括 Scrum of Scrums 之外的依赖关系）并实现跨团队协调和沟通，为团队和组织服务。他们负责通过发布有关产品开发进度、障碍消除状态和其他指标的信息，让首席产品负责人、利益相关者和更大的组织了解情况

EAT

Executive Action Team (EAT)，履行整个敏捷组织的 Scrum Master 职责。该领导团队创建了一个敏捷的生态系统，负责消除 Scrum of Scrums（或更广泛的网络）成员无法消除的障碍。因此，它必须由在政治和经济上有权消除他们的个人组成

EAT Backlog

执行行动团队 (EAT) 的产品是为组织创建敏捷操作系统。EAT 策划一个产品待办事项列表，其中包含组织持续转型的举措，以实现更高业务敏捷性的目标。该待办事项还包括流程改进，消除障碍和需要标准化的障碍

CPO

Chief Product Owner (CPO)与产品负责人团队协调优先级。他们共同将待办事项的优先事项与利益相关者和客户的需求结合起来。CPO 可能是扮演此角色的单个团队产品负责人，也可能是专门致力于此的人员。他们的主要职责与现在的常规产品负责人相同，与相关的 Scrum of Scrums Master 负责根据发布计划有效交付产品增量