Scrum是一个实现了敏捷思维的框架，帮助团队快速前进和学习，是一种把事情搞定的敏捷方法，Scrum常常与其他敏捷框架结合起来使用。Scrum认证是全球最权威和最流行的敏捷实践集。

Scrum认证由国际Scrum联盟（ScrumAlliance.org）制定和维护，针对个人职业发展的敏捷认证体系，Scrum认证证书由Scrum联盟官方统一颁发和维护。其中基础级认证面向Scrum团队的三个角色：ScrumMaster认证(CSM)、Scrum Product Owner认证(CSPO)和Scrum Developer认证(CSD)。UPerform敏捷学院是中国领先的Scrum认证及敏捷培训授权服务机构。

https://www.uperform.cn/scrum-certification-course/

Scrum Alliance总部位于美国，是一个为Scrum和敏捷实践者提供教育、资源和支持的组织。深入一步，你会发现Scrum联盟是观念和变革运动的一部分。Scrum联盟提供主张、社区参与、研究、人际网络和关注组织变革，这些变革正在改变着全球的工作方式。Scrum是一个非盈利组织，由全球超过50万认证者组成，驱使我们的不是商业，也不是什么财务盈亏；我们的动力正是来自于全球社区的成员，以及寻求实现真正工作与生活平衡的每个人。

2017年11月17-18日， 上海优普丰敏捷学院 Scrum Master中文认证公开课在上海世纪大道圆满落幕啦！

学员们现学现用，认真思考！！

Scrum 指南的目的

Scrum 是用于开发和持续支持复杂产品的一个框架。本指南包含了 Scrum 的定义，其中包 括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写与提供。总之，他们是 Scrum 指南的后盾。

Scrum 的定义

Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能

高效并创造性地交付尽可能高价值的产品。 Scrum 是:
 轻量级的
 易于理解的
 难以精通的

Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发 上。Scrum 并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加 清楚地显现出来，因此您可以去改进它们。

Scrum 框架由 Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部 分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。

Scrum 的规则把事件、角色和工件组织在一起，管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。

使用 Scrum 框架的其它不同特定技巧将不在本文中描述。

Scrum 的应用

Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范 围内已得到了广泛应用：

1. 研究与确定可行的市场、技术和产品能力；

2. 开发产品和增强功能；

3. 每天频繁多次发布产品和增强功能；

4. 开发和维护云（在线、安全、按需）和其他产品的运营环境；

5. 支持和更新产品。

Scrum 已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、学校、政府、 市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。

随着技术、市场和环境的复杂性及其它们之间相互作用的快速增长，Scrum 在处理复杂性方面的效用日益得到证实。

在迭代与增量的知识迁移中，Scrum 被证明特别有效。Scrum 现广泛用于产品、服务和母公司管理。

Scrum 的精髓在于小团队。个体团队具有高度灵活性和适应性。当单个、几个、多个和团队网络在开发、发布、运营和维护成千上万人的工作和工作产品时，这些优势得以持续运 作（并发挥价值）。他们通过精良的开发架构和目标发布环境来协作和互操作。

当 Scrum 指南使用“开发（动词）”和“开发（名词）”这两个词时，它们指的是复杂性的工作，包含上面提到的各种类型工作。

Scrum 理论

Scrum 基于实验性过程控制理论，也称之为经验主义(Empirical Process)。实验性过程主张知识源自实际经验以及从当前已知情况下做出决定所获得。Scrum 采用一种迭代、增量式的方法来优化对未来的 预测和管理风险。

透明、检视和调整是实验性过程控制的三大支柱，支撑起每一个实验性过程控制的实施。

透明

过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。

例如:
 所有参与者谈及过程时都必须使用统一的术语。同时，
 负责完成工作和验收工作的人必须对“完成”的定义，有一致的理解。

检视

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的 差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉 地执行时，效果最佳。

调整

如果检视者发现过程中的一个或多个方面偏离于可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化 进一步的偏离。

Scrum 规定了 4 个正式事件，用于检视与调整，这 4 个事件在 Scrum 事件章节中会加以 描述:

 Sprint计划会议

 每日 Scrum 站会

 Sprint评审会议

 Sprint回顾会议

Scrum 价值观

当投入、勇气、专注、开放和尊重五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和调整三大支柱成为现实，并且在每个人之间构建信任。Scrum 团队成员通过 Scrum 事件、角色和工件来学习和探索这些价值观。

Scrum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队 的目标。Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于 Sprint 和 Scrum 团队目标的工作。Scrum 团队及其利益攸关者同意将所有工作和执行工作 的挑战进行公开。Scrum 团队成员相互敬重，彼此成为更有能力和独立的人。

Scrum 团队

Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。Scrum 团队是跨职能 的自组织团队。自组织团队自己选择如何以最好的方式来完成工作，而不是由团队之外的 人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum 的团队模式乃是设计用来提供最佳的灵活性、创造力和生产力。

Scrum 团队迭代增量式地交付产品，籍此最大化获得反馈的机会。增量式交付“完成”的产 品保证了一个可工作产品的潜在可用版本总是存在。

产品负责人

产品负责人负责最大化产品和开发团队工作的价值。如何实现这一点的方式会随着组织、 Scrum 团队和单个团队成员的不同而不同。

产品负责人是负责管理产品待办列表的唯一责任人。产品待办列表的管理包括:

 清晰地表述产品待办列表项;
 对产品待办列表项进行排序，使其最好地实现目标和使命;
 优化开发团队所执行工作的价值;

 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做 的工作; 以及，

 确保开发团队对产品待办列表项有足够深的了解。 产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。

产品负责是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委 员会的期望要求，但是想要改变产品待办列表项的优先级必须经过产品负责人。

为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负 责人对产品待办列表的内容和排序的决定必须是可见的。任何人都不得要求开发团队按照 另一套需求开展工作，另一方面开发团队也不允许去做任何其他人所说的。

开发团队

开发团队包含了各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产 品增量。只有开发团队成员才能创建增量。

开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应 能最大化开发团队的整体效率和效用。

开发团队具有下列特点:

 他们是自组织的。没有人(即使是 Scrum Master)有权告诉开发团队应该如何把产品 待办列表变成潜在可发布的功能增量;

 开发团队是跨职能的，团队作为一个整体，拥有创建产品增量所需的全部技能;
 Scrum不认可开发团队成员的头衔，不管承担哪种工作他们都叫开发人员，即只有开发人员这一头衔。此规则无一例外;
 Scrum不认可开发团队中所谓的“子团队”，无论是否有特别的专业领域，例如无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无一例外; 同时,
 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

开发团队的规模

开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。 少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的 团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产 品增量。超过 9 人的团队则需要过多的协调沟通工作。过大的开发团队会产生太多的复杂 性，不便于经验过程管理。产品负责人和 Scrum Master 角色不包含在此数字中，除非他们 同时也参与执行 Sprint 待办列表中的工作。

Scrum Master

Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master 服务于产品负责人
Scrum Master 以各种方式服务于产品负责人，包括:

 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
 找到有效管理产品待办列表的技巧;
 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项;
 理解在经验主义的环境中的产品规划;
 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值;  理解并实践敏捷性;以及,
 按要求或需要引导 Scrum 事件。

Scrum Master 服务于开发团队
Scrum Master 以各种方式服务于开发团队，包括:

 在自组织和跨职能方面给予开发团队指导;

 帮助开发团队创造高价值的产品;
 移除开发团队工作进展中的障碍;
 按要求或需要引导 Scrum 事件; 以及,

 在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。

Scrum Master 服务于组织
Scrum Master 以各种方式服务于组织, 包括:

 带领并指导组织采纳 Scrum ;
 在组织范围内规划 Scrum 的实施;
 帮助员工和利益攸关者理解并实施 Scrum 和经验产品开发;
 引发能够提升 Scrum 团队生产效率的改变; 以及,
 与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性。

Scrum 事件

Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有 事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目 标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和调整的正式机会。这些事件都是被特别设计用来确保达成透明和检 视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与调整的机会。

Sprint

Sprint 是 Scrum 的核心，其长度(持续时间)为一个月或更短时间的限时，在这段时间内 构建一个“完成的”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长 度通常保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

Sprint 由 Sprint 计划会议、每日 Scrum 站会、日常开发工作、 Sprint 评审会议和 Sprint 回顾会议构成。

在 Sprint 期间:

 不能做出有害于 Sprint 目标的改变;

 不能降低质量的目标;以及,

 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会要澄清 和重新协商。

每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于 完成某些事情。每个 Sprint 都会定义要开发什么，还有一份设计过和灵活的计划用来指导 如何做这些事、工作内容和最终产品。

Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能 会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一 次对达成目标的进度进行检视和调整，来实现可预测性。Sprint 同时也把风险限制在一个 月的成本上。

取消 Sprint

Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然 他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。

如果 Sprint 目标过时，那么 Sprint 就会被取消。比如公司的发展方向或者市场上或技术上 的状况发生改变，这些变化都可能导致 Sprint 被取消。总的来说，如果某个 Sprint 对其所 在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短， 所以取消 Sprint 的意义不大。

当取消某个 Sprint 时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何 部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表 项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以 必须经常性地重估。

取消 Sprint 会消耗资源，因为每个人都必须重新集合在另一个 Sprint 计划会议来开始另一 个 Sprint 。取消 Sprint 通常会对 Scrum 团队造成重创，这种情况非常罕见。

Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共 同协作完成的。

Sprint 计划会议是限时的，以一个月的 Sprint 来说最长 8 小时为上限。对于较短的 Sprint， 会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的 目的。 Scrum Master 要教导 Scrum 团队遵守时间盒的规则。

Sprint 计划会议回答以下问题:
 接下来的 Sprint 交付的增量中要包含什么内容?

 要如何完成交付增量所需的工作?

话题一: 这次 Sprint 能做什么?
开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该目 标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预 测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团 队可以评估接下来的 Sprint 可以完成什么工作。

在开发团队预测完这个 Sprint 中可交付的产品待办列表项之后，Scrum 团队草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为 开发团队提供指引，使得开发团队明确开发增量的目的。

话题二: 如何完成所选的工作?

在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如 何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表 项加上交付它们的计划称之为 Sprint 待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中，开 发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天 或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。如果开发团队认为 工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可 以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如 何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

Sprint 目标

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指 引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标为 开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个 连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使开发团 队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能 和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

每日 Scrum 站会

每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件。每日 Scrum 站会在 Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计 划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队 协作和性能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。

开发团队借由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每 天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出预期中的增量。

会议的结构由开发团队设定。如果会议专注于达成 Sprint 目标的进展，开发团队可以采 用不同的方式进行。一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨 论来开会。以下为示例：

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？

• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？

• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。

Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。

每日 Scrum 站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。

每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显 并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与调整的关键会议。

Sprint 评审会议

Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办 列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的 工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可 能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的 目的是为了获取反馈并促进合作。

对于长度为一个月的 Sprint 来说，评审会议时间最长不超过 4 小时。对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议 的目的。Scrum Master 教导每位参会者遵守时间盒的规则。

Sprint 评审会议包含以下内容:

  产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议;
  产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
  开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决 的;
  开发团队演示“完成”的工作并解答关于所交付增量的问题;
  产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的完成日期(如果有需要的话);
  参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的Sprint 计划会议提供有价值的输入信息;
  评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变;同时，
  为下个预期产品版本的发布评审时间表、预算、潜力和市场。
Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品 待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。

Sprint 回顾会议

Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

Sprint 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为 一个月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时间通常会缩 短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员参加 该会议。

Sprint 回顾会议的目的在于:
 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何;

 找出并加以排序做得好的和潜在需要改进的主要方面;同时,

 制定改进 Scrum 团队工作方式的计划。

Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，Scrum 团队通过适当地调整“完 成”的定义的方式来计划提高产品质量。

在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和调整的正式机会。

Scrum 工件

Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和调整的机会。Scrum 所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个人对工件都需要有相同的理解。

产品待办列表

产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变动 的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。

产品待办列表永远是不完整的。最早开发的产品待办列表只列举最初所知的以及理解最透 彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态 的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。只要产品存 在，产品待办列表也就同样存在。

产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的改 变。产品待办列表项具有这些属性:描述、次序、估算和价值。

随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的 列表。因为需求永不停止改变，所以产品待办列表就如一份活的工件。业务需求、市场形 势或者技术的变化都会引起产品待办列表的改变。

多个 Scrum团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用于 描述下一步产品开发工作。那么这就可能需要使用能够对产品待办列表项进行分组的属 性。

产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续 的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精 化过程中，产品待办列表项被重新评审和修改。Scrum 团队决定如何来完成精化以及何时来完成。精化的工作通常占用开发团队不超过 10% 的产能。然而，产品负责人或者其他人 在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。

排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容 和更详尽的细节信息就能做出更为准确的估算;同样，排序越低，则细节信息越少。产品 待办列表项中那些即将会占用开发团队下一个 Sprint 大部分时间的项会被加以精化，因此，任一产品待办列表项都能够在 Sprint 的时间盒期限内适当地“完成”。这些能够被开发 团队在一个 Sprint 中“完成”的产品待办列表项称为“准备就绪”，它们将作为 Sprint 计划会 议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的精化活动来获得。

开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据 情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。

监控目标实现的进度

在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个 Sprint 评审会议 中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前 Sprint 评审会议时 的剩余工作量，来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关者都 是透明的。

各种不同趋势走向的实践已经被使用在预测进度方面，例如，燃尽图(burn-downs)、燃 烧图(burn-ups)或者累积流图(cumulative flows)。这些工具都被证实是有用的。然而，它们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法 预知的。只有已经发生的事才能用来做前瞻性的决策。

Sprint 待办列表

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以 及交付那些功能到“完成”的增量中所需工作的预测。

Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在先前回顾会议中确定下来的高优先级过程改进。

Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中清 晰地看到。开发团队在 Sprint 期间修改 Sprint 待办列表，使得 Sprint 待办列表在 Sprint 期 间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达成 Sprint 目标所必需的工作时。

当新工作出现时，开发团队需要将其加入到 Sprint 待办列表中去。随着工作的执行或完 成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。 在 Sprint 期间，只有开发团队可以改变 Sprint 待办列表。Sprint 待办列表是高度可见的， 是对开发团队计划在当前 Sprint 内工作完成情况的实时反映，该列表由开发团队全权负责。

监控 Sprint 进度

在 Sprint 的任何时间点都可以计算 Sprint 待办列表中所有剩余工作的总和。开发团队至少 在每日 Scrum 站会时跟踪剩余的工作量，预测达成 Sprint 目标的可能性。通过在 Sprint 中不断跟踪剩余的工作量，开发团队可以管理自己的进度。

增量

增量是一个 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 团队中的开发团队必须一起参与制定 “完成”的定义。

每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有 增量都能工作。

随着团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量。任何产 品或系统都应该对其上面开发的工作有“完成”的定义。

结束语

Scrum 是免费的，在本指南中提供。Scrum 的角色、工件、事件和规则是不可改变的。虽然只实施部分的 Scrum 是可能的，但这样就不是 Scrum 了。Scrum 只以整体的形式而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。

致谢

人们

在千千万万对 Scrum 作出贡献的人中，我们要特别感谢那些在其最初十年提供帮助的人们。首先，要提到 Jeff Sutherland 以及与他一道工作的 Jeff McKenna，还有 Ken Schwaber 及与其一道工作的 Mike Smith 与 Chris Martin 。在随后的几年中，许多人都作出了贡献， 没有他们的帮助，Scrum 不会被提炼至如今这般。

历史

Ken Schwaber 和 Jeff Sutherland 在 1995 年举行的 OOPSLA 大会上首次联合公开演讲 Scrum。那次演讲本质上记录了 ken 和 Jeff 在之前几年间使用 Scrum 时所学到的经验。

在软件开发的世界中，Scrum 的历史已经算是很长了。我们对首批尝试和提炼 Scrum 的公司: Individual，Inc.、 Fidelity Investments 和 IDX(现在的 GE 医疗)表示致敬。

Scrum 指南记录 Jeff Sutherland 和 Ken Schwaber 开发和培育 Scrum 已经超过 20 多年了。其他的一些资源从模式、流程和见解方面为 Scrum 框架提供了补充，从而优化生产效率、价 值、创造力及提升自豪感。

翻译

本中文指南( 2017 版 )是从 Jeff Sutherland 和 Ken Schwaber 联合撰写的《 Scrum 指南》 ( 2017 版)的英文原版翻译而来。链接 http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Chinese-Simplified.pdf

译者:周建成 (Agile Coach)

修订: Jacky Shen (CST, CTC)

Scrum指南的目的

在 1990 年代初，我们开发了 Scrum。在 2010 年，我们撰写首版 Scrum 指南，以帮助全世界的人们理解 Scrum。自那时起，我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。

Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的，这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则，将掩盖问题并限制 Scrum 的好处，甚至可能变得毫无用途。

我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到Scrum 在许多本质上具有复杂性的工作领域中被采用，超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大，开发者（developers）、研究人员、分析师、科学家和其他专家都能在工作中应用。因此，我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者，而是为了简化统称。如果您从 Scrum 中获得价值，那么您可以将自己视为其中一员。

在使用 Scrum 时，可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。对它们的描述超出了 Scrum 指南的目的，因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异，因此不在本文中描述。

Scrum 的定义

Scrum 是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值。

简而言之，Scrum 需要 Scrum Master 营造一个环境，从而：

1. 一名产品负责人将解决复杂问题所需的工作整理成一份产品待办列表。
2. Scrum 团队在 一个 Sprint 期间将选择的工作转化为价值的增量。
3. Scrum 团队和利益攸关者检视结果并为下一个 Sprint 进行调整。
4. 重复

Scrum 是易于理解的。原封不动地去尝试，并确定其哲学、理论和结构是否有助于实现目标和创造价值。 Scrum 框架故意不完整，仅定义了实施 Scrum 理论所需的部分。Scrum 建立在其使用者的集体智慧之上。Scrum 的规则没有为人们提供详细的使用说明，而是指导他们之间的关系和互动。

在 Scrum 框架中，可以使用各种不同的过程、技术和方法。Scrum可以将一些已有的实践包装进来，也可以甄别出非必须的实践。Scrum 可以凸显当前管理、环境和工作技术的相对成效，以便可以进行改进。

Scrum 理论

Scrum 基于经验主义和精益思维。 经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。

Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。 Scrum 让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。

Scrum 将四个正式事件组合在一起以在一个容器型事件 Sprint 中进行检视和适应。这5个事件之所以起作用，是因为它们实现了基于经验主义的 Scrum 的三个支柱：透明、检视和适应。

透明（Transparency）

涌现的过程和工作成果必须对执行工作的人员和接受工作的人员都是可见的和一致理解的。在 Scrum 中，重要的决策是基于其 3 个正式工件的感知状态。透明度较低的工件可能导致做出降低价值并增加风险的决策。

透明使检视成为可能。没有透明和共识的检视会产生误导和浪费。

检视（Inspection）

Scrum 工件和实现商定目标的进展必须经常地和勤勉地检视，以便发现潜在的不良的差异或问题。为了帮助检视，Scrum 以 5 个事件的形式提供了稳定的节奏。

检视使适应成为可能。没有适应的检视是毫无意义的。Scrum 事件旨在激发改变。

调整（Adaptation）

如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或过程处理的内容加以调整。 调整工作必须尽快执行以最小化进一步的偏差。

当所涉人员没有得到授权或不能自管理时，则适应将变得更加困难。 在通过检视学到任何新东西时，Scrum 团队会做出相应调整。

Scrum 价值观

Scrum 的成功应用取决于人们变得更加精通践行并内化 5 项价值观：

承诺， 专注， 开放， 尊重，勇气

Scrum 团队致力于达成其目标并且相互支持。他们主要专注于 Sprint 的工作，以便尽可能地向着这些目标获取最好的进展。 Scrum 团队及其利益攸关者对工作和挑战持开放态度。 Scrum 团队成员相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的人的尊重。Scrum 团队成员有勇气做正确的事并处理那些棘手的问题。

这些价值观为 Scrum 团队的工作、行动和行为指引方向。做出的决定、采取的步骤以及使用Scrum 的方式应强化这些价值观，而不是削弱或破坏它们。Scrum 团队成员通过 Scrum 事件和工件来学习和探索这些价值观。当 Scrum 团队和与他们一起工作的人们体现这些价值观时，基于经验主义的 Scrum 的三个支柱：透明、检视和适应，就成为现实，并在每个人之间构建信任。

Scrum 团队（Scrum Team）

Scrum 的基本单位是小团队，称为 Scrum Team。 Scrum 团队由一名 Scrum Master，一名产品负责人和开发人员组成。在 Scrum 团队中，没有子团队或层次结构。Scrum 团队是具有凝聚力的专业团体，一次专注于一个目标，即产品目标。

Scrum 团队是跨职能的，这意味着团队成员具有在每个 Sprint 中创造价值而所需的全部技能。他们也是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。

Scrum 团队规模足够小以保持灵活，同时足够大以便可以在一个 Sprint 中完成有意义的工作，通常只有 10 人或更少。总的来说，我们发现较小的团队沟通更好，效率更高。如果 Scrum 团队变得太大，则应考虑将他们重组为多个具有凝聚力的 Scrum 团队，每个团队都专注于同一产品。因此，他们应该共享相同的产品目标、产品待办列表和产品负责人。

Scrum 团队负责所有与产品相关的活动，包括与利益攸关者的协作、验证、维护、运营、实验、研究和开发，以及可能需要进行的其他任何活动。组织组建并授权 Scrum 团队自行管理他们自己的工作。以可持续的速度在 Sprint 中工作可以提高 Scrum 团队的专注度和一致性。

整个 Scrum 团队都有责任在每个 Sprint 中创建有价值的、有用的增量。 Scrum 在 Scrum 团队中定义了三种特定的职责担当（Accountability）：开发人员、产品负责人和 Scrum Master。

开发人员（Developers）

开发人员是 Scrum 团队中致力于创建每个 Sprint 可用增量的任何方面的人员。

开发人员所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。但是， 开发人员始终要负责：

• 为Sprint创建计划，即 Sprint 待办列表；
• 通过遵循完成的定义来注入质量；
• 每天根据 Sprint 目标调整计划； 和，
• 作为专业人士对彼此负责。

产品负责人（Product Owner）

产品负责人负责将 Scrum 团队的工作所产生的产品价值最大化。 如何做到这一点可能在组织、Scrum 团队和个体之间存在很大差异。

产品负责人还负责对产品待办列表进行有效管理，包括：

• 开发并明确地沟通产品目标；
• 创建并清晰地沟通产品待办列表项；
• 对产品待办列表项进行排序； 和，
• 确保产品待办列表是透明的、可见的和可理解的。

产品负责人可以自己做上述工作，或者也可以将职责委托他人。 然而无论如何， 产品负责人是担当最终责任的人。

为保证产品负责人取得成功，整个组织必须尊重他们的决定。这些决定在产品待办列表的内容和顺序中可见，并在 Sprint 评审会议时透过可检视的增量予以体现。

产品负责人是一个人，而不是一个委员会。在产品待办列表中，产品负责人可以代表许多利益攸关者的期望要求。那些想要改变产品待办列表的人可以尝试去说服产品负责人来做到这一点。

Scrum Master （敏捷教练和领导者）

Scrum Master 负责按照 Scrum 指南的游戏规则来建立 Scrum。他们通过帮助 Scrum 团队和组织内的每个人理解 Scrum 理论和实践来做到这一点。

Scrum Master 对 Scrum 团队的效能负责。他们通过让 Scrum 团队在 Scrum 框架内改进其实践来做到这一点。

Scrum Masters 是真正的领导者，服务于 Scrum 团队和作为更大范围的组织。

Scrum Master 以多种方式服务于 Scrum 团队，包括：

• 作为教练在自管理和跨职能方面辅导 Scrum 团队成员；
• 帮助 Scrum 团队专注于创建符合完成的定义的高价值增量；
• 促使移除 Scrum 团队工作进展中的障碍；和，
• 确保所有 Scrum 事件都发生并且是积极的、富有成效的，并且在时间盒内完成。

Scrum Master 以多种方式服务于产品负责人，包括：

• 帮助找到有效定义产品目标和管理产品待办列表的技巧；
• 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
• 帮助建立针对复杂环境的基于经验主义的产品规划；和，
• 当需要或被要求时，引导利益攸关者协作。

Scrum Master 以多种方式服务于组织，包括：

• 带领、培训和作为教练辅导组织采纳 Scrum；
• 在组织范围内规划并建议 Scrum 的实施；
• 帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法；和，
• 消除利益攸关者和 Scrum 团队之间的隔阂。

Scrum 事件

Sprint 是所有其他事件的容器。Scrum 中的每个事件都是检视和适应 Scrum 工件的正式机会。这些事件都是为实现所需的透明度而特别设计的。未能按规定运作任何事件将导致失去检视和适应的机会。Scrum 使用事件来创造规律性，并以此最小化对 Scrum 中未定义的会议的需要。 最理想的是，所有事件都在同一时间同一地点举行，以便减少复杂性。

Sprint （短迭代时间盒）

Sprint 是 Scrum 的核心，在这里创意转化为价值。

它们是固定时长的事件，为期一个月或更短，以保持一致性。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。

实现产品目标所需的所有工作，包括 Sprint 计划会议、每日 Scrum 会议、Sprint 评审会议和 Sprint 回顾会议，都发生在 Sprint 内。

在 Sprint 期间：

• 不能做出危及 Sprint 目标的改变；
• 不能降低质量；
• 产品待办列表按需进行精化，和
• 随着学到更多，可以与产品负责人就范围加以澄清和重新协商。

Sprint 通过确保至少每个自然月一次对达成产品目标的进展进行检视和适应，来实现可预测性。当 Sprint 的时间长度拉得太长时，Sprint 目标可能会失效，复杂性可能会上升，同时风险可能会增加。可以使用较短的 Sprint 来产生更多的学习周期，并将成本与工作投入的风险限制在更短的一段时间内。每个 Sprint 都可以视为一个短期的项目。

存在各种各样的实践来预测进展，例如，燃尽图、燃起图或累积流图。尽管被证明是有用的，然而这些实践并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生什么是未知的。只有已经发生的事情才能用来做前瞻性的决策。

如果 Sprint 目标已过时，那么就可以取消 Sprint。只有产品负责人拥有取消 Sprint 的权力。

Sprint 计划会议（Sprint Planning）

Sprint 计划会议通过安排在 Sprint 中要做的工作来启动 Sprint。最终的计划是由整个 Scrum 团队协作创建的。

产品负责人要确保与会者准备好讨论最重要的产品待办列表项 ，以及它们如何映射到产品目标。Scrum 团队还可以邀请其他人参加 Sprint 计划会议以提供建议。

Sprint 计划会议处理以下话题：

话题一：为什么这次 Sprint 有价值？

产品负责人提议产品如何在当前的 Sprint 中增加其价值和效用。然后，整个 Scrum 团队将共同制定一个 Sprint 目标，用以沟通当前 Sprint 对利益攸关者有价值的原因。必须在 Sprint 计划会议结束之前最终确定 Sprint 目标。

话题二：这次 Sprint 能完成（Done）什么？

通过与产品负责人讨论， 开发人员从产品待办列表中选择一些产品待办列表项，放入当前 Sprint 中。 Scrum 团队可以在此过程中精化这些产品待办列表项，从而增加理解和信心。

选择在 Sprint 中可以完成多少任务可能会有挑战。 但是，开发人员对他们以往的表现，他们在即将到来的 Sprint 内的产能以及对他们的完成的定义了解得越多，他们对 Sprint 预测就越有信心。

话题三：如何完成所选的工作？

对于每个选定的产品待办列表项，开发人员都会规划必要的工作，以便创建符合完成的定义的增量。这通常是通过将产品待办列表项分解为一天或更短的较小项来完成的。开发人员自行决定如何完成这一工作。没有人告诉他们如何将产品待办列表项转化为价值的增量。

Sprint 目标、这次 Sprint 所选出的产品待办列表项加上如何交付它们的计划称之为 Sprint 待办列表。

Sprint 计划会议是有时间盒限定的，以一个月的 Sprint 来说最多为 8 个小时。对于更短的 Sprint，Sprint 计划会议所需时间通常会更短。

每日 Scrum 会议（Daily Scrum）

每日 Scrum 会议的目的是检视达成 Sprint 目标的进展，并根据需要调整适应 Sprint 待办列表，以调整即将进行的计划工作。

每日 Scrum 会议是一个属于 Scrum 团队的开发人员的 15 分钟的事件。为了降低复杂性，它在 Sprint 的每个工作日都在同一时间同一地点举行。如果产品负责人或 Scrum Master 正在积极处理 Sprint 待办列表上的项，那么他们将作为开发人员参与其中。

开发人员可以选择他们想要的任何举行每日 Scrum 会议的结构和技术，只要他们专注于实现 Sprint 目标的进展，并为下一工作日的工作制定可行的计划即可。这可以创建专注点并改进自管理。

每日 Scrum 会议改善沟通，发现障碍，促进快速决策，从而消除其他会议的需要。

每日 Scrum 会议并不是唯一一次允许开发人员调整计划的时间。他们可以在一天中任何时间碰面，详细讨论如何调整适应或重新规划 Sprint 的剩余工作。

Sprint 评审会议（Sprint Review）

Sprint 评审会议的目的是检视 Sprint 的成果并确定未来的适应性。Scrum 团队向关键利益攸关者展示他们的工作结果，并讨论产品目标的进展情况。

在 Sprint 评审会议期间，Scrum 团队和利益攸关者将评审在这次 Sprint 中完成了什么，以及环境发生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。产品待办列表也可能会进行调整以适应新的机会。Sprint 评审会议是一个工作会议，Scrum 团队应避免将其仅限于展示。

Sprint 评审会议是 Sprint 的倒数第二个事件，Sprint 评审会议是有时间盒限定的，以一个月的 Sprint 来说，最多为 4 个小时。 对于更短的 Sprint，Sprint 评审会议通常所需的时间更短。

Sprint 回顾会议（Sprint Retrospective）

Sprint 回顾会议的目的是规划提高质量和效能的方法。

Scrum 团队检视最近 Sprint 中有关个体、交互、过程、工具和他们的完成的定义的情况如何。被检查的元素通常随工作领域而变化。识别使他们误入歧途的假设，并探究其起源。Scrum 团队讨论在 Sprint 期间哪些进展顺利，遭遇到哪些问题以及这些问题是如何解决（或未解决）的。

Scrum 团队识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个 Sprint 的 Sprint 待办列表中。

Sprint 回顾会议结束 Sprint。它是有时间盒限定的，以一个月的 Sprint 来说，最多为 3 个小时。对于更短的 Sprint， Sprint 回顾会议通常所需的时间更短。

Scrum 工件（Scrum Artifacts)

Scrum 的工件代表工作或价值。 它们旨在最大限度地提高关键信息的透明度。 因此，为适应而检视它们的每个人对工件都有相同的基础。

每个工件都包含一个承诺，以确保它提供可增强透明度并聚焦于可度量进展的信息：

• 对于产品待办列表而言，它是产品目标。
• 对于 Sprint 待办列表而言，它是 Sprint 目标。
• 对于增量而言，它是完成的定义。

这些承诺的存在是为了强化经验主义和 Scrum 团队及其利益攸关者的 Scrum 价值观。

产品待办列表（Product Backlog）

产品待办列表是一份涌现的和有序的清单，它列出了改进产品所需的内容。它是 Scrum 团队所承担工作的唯一来源。

能够被 Scrum 团队在一个 Sprint 中完成（Done）的产品待办列表项被认为准备就绪，在 Sprint 计划会议事件中可供选择。它们通常在精化活动后获得这种透明度。产品待办列表精化是将产品待办列表项分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为产品待办列表项增添细节，例如描述、优先顺序和规模。这些属性通常随工作领域而变化。

将要做这项工作的开发人员负责使其适当的大小。产品负责人可以通过帮助开发人员理解和权衡取舍来影响他们。

承诺：产品目标（Product Goal）

产品目标描述了产品的未来状态，可以作为 Scrum 团队制定计划的目标。产品目标在产品待办列表中。产品待办列表的其余部分涌现，用来定义“做什么”将实现产品目标。

产品是传递价值的载体。它具有明确的边界、已知的利益攸关者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。

产品目标是 Scrum 团队的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一个目标。

Sprint 待办列表（Sprint Backlog ）

Sprint 待办列表由 Sprint 目标（为什么做）、为 Sprint 选择的产品待办列表项（做什么）以及交付增量的可执行计划（如何做）组成。

Sprint 待办列表是开发人员为其制定的计划。它是开发人员在 Sprint 期间为实现 Sprint 目标而计划完成的工作，是一个高度可视且实时的工作画面。因此，随着学到更多，Sprint 待办列表在整个 Sprint 期间会进行更新。它应该有足够的细节，以便他们可以在每日 Scrum 会议中检视其进展。

承诺： Sprint 目标（Sprint Goal）

Sprint 目标是 Sprint 的单个目标。尽管 Sprint 目标是开发人员的承诺，但它为实现该目标所需的确切工作方面提供了灵活性。 Sprint 目标还创造了连贯性和专注点，鼓励 Scrum 团队一起工作而不是分开独自行动。

Sprint 目标在 Sprint 计划会议事件中确定，然后添加到 Sprint 待办列表中。当开发人员在 Sprint 期间工作时，他们将 Sprint 目标铭记在心。如果需要做的工作与预期的不同，他们将与产品负责人协作，在不影响 Sprint 目标的情况下，协商本次 Sprint 待办列表的范围。

增量（Increment）

一个增量是迈向产品目标的一块坚实垫脚石。每个增量都是之前所有的增量累加起来的，并经过彻底地验证，以确保整合在一起的所有增量都能工作。为了提供价值，增量必须是可用的。

在一个 Sprint 中可以创建多个增量。 增量的总和在 Sprint 评审会议中展示，从而支持经验主义。 但是，增量可以在 Sprint 结束之前交付给利益攸关者。Sprint 评审会议决不应该被视为发布价值的关口。

一项工作除非符合完成的定义，否则不能将其视为增量的一部分。

承诺： 完成的定义（Definition of Done）

完成的定义是当增量符合产品所需的质量度量标准时对其状态的正式描述。

当一个产品待办列表项符合完成的定义时，就会产生一个增量。

完成的定义通过使每一个人对作为增量的一部分、什么样的工作算是已完成的工作有一个共同的理解来创建透明。如果一个产品待办列表项不符合完成的定义，那么它就不能发布，甚至不能在 Sprint 评审会议中展示它。相反，它返回到产品待办列表中以供将来考虑。

如果增量的完成的定义是组织标准的一部分，那么所有 Scrum 团队都必须以此为最低标准来遵守。如果它不是组织标准的一部分，那么 Scrum 团队必须制定适合于该产品的完成的定义 。

开发人员需要遵守完成的定义。如果有多个 Scrum 团队在同一产品上一起工作，那么他们必须一起制定并遵守同样的完成的定义。

结束语

Scrum 是免费的，并在本指南中提供。本文概述的 Scrum 框架是不可改变的。虽然仅实施部分的 Scrum 是可能的，但其结果就不是 Scrum 了。Scrum 仅以完整形式而存在，唯其如此才能有效成为其他技术、方法和实践的容器。

致谢

人们

在为 Scrum 作出贡献的成千上万的人中，我们要特别指出那些在其最初提供帮助的人们：Jeff Sutherland 以及与他一道工作的 Jeff McKenna 和 John Scumniotales，还有 Ken Schwaber 以及与他一道工作的 Mike Smith 和 Chris Martin，他们一起工作 。 在随后的几年中，许多其他人作出了贡献，如果没有他们的帮助，Scrum 不会被提炼至如今这般。

Scrum 指南历史

在 1995 年的 OOPSLA 大会上，Ken Schwaber 和 Jeff Sutherland 首次联合公开演讲 Scrum。这场演讲本质是 Ken 和 Jeff 在之前数年运用 Scrum 积累所得的记录，并首次公开提出 Scrum 的正式定义。

Scrum 指南记录了 Jeff Sutherland 和 Ken Schwaber 在 30 多年间对 Scrum 的开发、演进和维护。此外，其他一些资源在模式、过程和见解方面为 Scrum 框架提供了补充。这些可能可以提高生产力、价值、创造力和对结果的满意度。

Scrum 的完整历史在其他地方也有记载。我们向首先尝试和证实 Scrum 的公司：Individual Inc.，Newspage，Fidelity Investments 和 IDX（现为 GE 医疗）表示致敬。

附：从2017 版到 2020 版指南的变更

规定性更低

这些年来，Scrum 指南开始变得越来越有规定性。 2020 版旨在通过删除或淡化规定性语言，使 Scrum 重新成为最低限度的框架。例如删除了每日 Scrum 会议三个提问，淡化了关于产品待办列表项属性的相关描述，淡化了 Sprint 待办列表中改进项的相关描述，删除了“取消 Sprint”一节更改为更为简单的描述 ，等等。

一个团队，专注于一个产品

我们的目标是消除导致产品负责人和 Dev 团队之间出现“代理”或“我们与他们”行为的团队中独立团队的概念。现在只有一个 Scrum 团队专注于同一目标，有三种不同的职责担当：产品负责人、ScrumMaster 和开发人员。

产品目标介绍

2020 版 Scrum 指南引入了产品目标的概念，为 Scrum 团队提供了一个更具价值的目标的专注点。每个 Sprint 都应使产品更接近整体的产品目标。

给 Sprint 目标、完成的定义和产品目标安了家

之前版本的 Scrum 指南描述了 Sprint 目标和完成的定义，但是没有真正赋予它们一个身份。 它们不是完全意义上的工件，而是在某种程度上依附于工件。 随着产品目标的增加，2020 版对此提供了更为清晰的说明。现在，三个工件中的每一个都包含一个相应的的“承诺”。 对于产品待办列表，它是产品目标，对于 Sprint 待办列表 则是 Sprint 目标，而增量则是完成的定义（现在，完成不再加引号）。它们的存在是为了带来透明度，并专注于每个工件的进展。

自管理胜过自组织

之前版本的 Scrum 指南将开发团队称为自组织，选择谁和如何做。 2020 版更关注 Scrum 团队，强调一个自管理的 Scrum 团队，选择谁、如何做以及做什么。

三个 Sprint 计划会议话题

Sprint 计划会议的话题除了“什么”和“如何”之外， 2020 版 Scrum 指南还强调了第三个话题“为什么”，即 Sprint 目标。

为更广泛的受众而全面简化语言

2020 版 Scrum 指南着重于消除冗余和复杂的陈述，以及删除所有与 IT工作相关的推断（例如，测试、系统、设计、需求，等等）。现在， Scrum 指南不到 13 页。

© 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons. 使用本 Scrum 指南，您认可以及同意以知识共享许可协议的署名-相同方式共享的条款。

PDF下载链接

https://www.uperform.cn/wp-content/uploads/2020/11/2020-Scrum-Guide-Chinese-Simplified.pdf

Purpose of the Scrum Guide

Scrum is a framework for developing, delivering, and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Definition of Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

• Lightweight
• Simple to understand
• Difficult to master

Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.

Specific tactics for using the Scrum framework vary and are described elsewhere.

Uses of Scrum

Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:

1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
5. Sustain and renew products.

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.

As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.

Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.

When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.

Scrum Theory

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Transparency

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

For example:

• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those inspecting the resulting increment must share a common definition of “Done”.

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Scrum Values

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

The Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

The Product Owner

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

The Scrum Master

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Topic Two: how will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.

The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Scrum Artifacts

Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Monitoring Progress Toward Goals

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”. An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

Artifact Transparency

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

Definition of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done”.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”.

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

End Note

Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Acknowledgements

People

Of the thousands of people who have contributed to Scrum, we should single out those who were instrumental at the start: Jeff Sutherland worked with Jeff McKenna and John Scumniotales, and Ken Schwaber worked with Mike Smith and Chris Martin, and all of them worked together. Many others contributed in the ensuing years and without their help Scrum would not be refined as it is today.

History

Ken Schwaber and Jeff Sutherland worked on Scrum until 1995, when they co-presented Scrum at the OOPSLA Conference in 1995. This presentation essentially documented the learning that Ken and Jeff gained over the previous few years, and made public the first formal definition of Scrum.

The history of Scrum is described elsewhere. To honor the first places where it was tried and refined, we recognize Individual, Inc., Newspage, Fidelity Investments, and IDX (now GE Health).

The Scrum Guide documents Scrum as developed, evolved, and sustained for 20-plus years by Jeff Sutherland and Ken Schwaber. Other sources provide you with patterns, processes, and insights that complement the Scrum framework. These may increase productivity, value, creativity, and satisfaction with the results.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons.