Scrum官网地址：https://www.scrum.org/。 Scrum官网帮助文档：https://www.scrumguides.org/index.html。
Scrum 是用于开发、交付和持续支持复杂产品的一个框架。 Scrum 并不是一种过程、技术或决定性方法。它是一个框架，在该框架中可以使用各种不同的过程和技术。 Scrum 中包含角色、事件、工件和规则。Scrum 的规则把角色、事件和工件组织在一起，管理他们之间的关系和交互。
Scrum 最初是为了管理和开发产品而开发的。Scrum 的精髓在于小团队。 Scrum 基于经验过程控制理论，Scrum 采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。
透明、检视、适应 是经验过程的三大支柱，支撑起每一个经验过程的实施。
过程中的关键环节对于那些产出负责的人必须是显而易见的。 要透明，就要为这些关键环节制定统一标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。
例如：
- 所有参与者谈及过程时都必须使用统一的疏于。
- 负责完成工作和检视结果增量的人必须对"完成"的定义，达成一致的理解。
Scrum 的使用者必须经常检视Scrum的工作和完成Sprint目标的进展，以便发现不必要的差异。 检视不应该过于频繁而阻碍工作本身。
如果检视者发现过程中的一个或者多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。
Scrum 规定了4个正式事件，用于检视和适应上：
- Sprint 计划会议
- 每日 Scrum 站会
- Sprint 评审会议
- Sprint 回顾会议
承诺、勇气、专注、开放和尊重五大价值观为Scrum团队所践行与内化时，Scrum的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。 Scrum 团队成员通过 Scrum 的角色、事件和工件来学习和探索这些价值观。
Scum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队的目标。 每个人专注于 Sprint 工作和 Scrum 团队的目标。
Scrum 团队由一名产品负责人、开发团队、一名 Scrum Master 组成。 Scrum 是跨职能的自组织团队，自组织团队如何选择以最好的方式完成工作，而不是由团队之外的人来指导。 跨职能团队拥有完成工作的所需全部技能，不需要依赖团队之外的人。
Scrum 团队迭代增量式地交付产品 ，借此最大化获得反馈的机会。增量式交付“完成”的产品保证了一个可工作产品的潜在可用版本总是存在。
产品负责人的职责是将开发团队开发的产品价值最大化。 产品负责人是负责管理产品代办列表的唯一负责人。
产品待办列表的管理包括：
- 清晰的表述产品待办列表项
- 对产品待办列表项进行排序
- 优化开发团队所执行工作的价值
- 确保产品待办列表对所有人是可见、透明和清晰的，同时 Scrum 团队下一步要做的工作
- 确保开发团队对产品待办列表项有足够深的了解
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。 产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表项展现一个委员会的期望要求，但是想要改变产品代办列表项的优先级都必须经过产品负责人。
为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重其决定。 产品负责人对产品待办列表的内容和排序的据欸的那个必须是可见的。 没有人可以强迫开发团队按照另一套需求开展工作。
开发团队包括各种人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必须的。只有开发团队成员才能创建增量。
开发团队具有下列特点：
- 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
- 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
- Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
- Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
- 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在开发团队人数中，除非他们同时也参与执行 Sprint 待办列表中的工作。
Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。
Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。
Scrum Master 以各种方式服务于产品负责人，包括：
- 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
- 找到有效管理产品待办列表的技巧；
- 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
- 理解在经验主义的环境中的产品规划；
- 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
- 理解并实践敏捷性；以及，
- 当被请求或需要时，引导 Scrum 事件。
Scrum Master 以各种方式服务于开发团队，包括：
- 作为教练在自组织和跨职能方面给予开发团队以指导；
- 帮助开发团队创造高价值的产品；
- 移除开发团队工作进展中的障碍；
- 按被请求或需要时，引导 Scrum 事件；以及，
- 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
Scrum Master 以各种方式服务于组织，包括：
- 带领并作为教练指导组织采纳 Scrum；
- 在组织范围内规划 Scrum 的实施；
- 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
- 引发能够提升 Scrum 团队生产率的改变；以及，
- 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint开始，它的持续时间是固定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即结束，如此确保时间被适当地使用而不会造成过程中的浪费。 Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint 不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。
Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。
Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议 以及 Sprint 回顾会议 构成。
在 Sprint 期间：
- 不能做出有害于 Spriunt 目标的改变
- 不能降低低质量的目标
- 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可以加以澄清和重新协商
每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用于完成某些事情。每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。
Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个月的成本上。
Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。
如果 Sprint 目标过时，那么 Sprint 就会被取消。比如公司的发展方向或者市场上或技术上的状况发生改变，这些变化都可能导致 Sprint 被取消。总的来说，如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短，所以取消 Sprint 通常是不太合理的。
当取消某个 Sprint 时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以必须经常性地重估。
取消 Sprint 会消耗资源，因为每个人都重新集合在另外一个 Sprint 计划会议来开始另一个 Sprint 。取消 Sprint 通常会对 Scrum 团队造成重创，这种情况非常罕见。