Scrum Events
Sprint是所有其他事件的容器。 Scrum中的每个事件都是检查和适应Scrum工件的正式机会。 这些事件是专门为实现所需的透明度而设计的。 未能按规定操作任何事件会导致失去检查和适应的机会。 Scrum中使用事件来创建规律性，并最小化对Scrum中未定义会议的需求。
最理想的是，所有事件都在同一时间和地点进行，以减少复杂性。
冲刺 The Sprint
Sprint是Scrum的心跳，在这里想法被转化为价值。
它们是为期一个月或更短时间的固定长度事件，以保持一致性。新的Sprint在上一次Sprint结束后立即开始。
实现产品目标所需的所有工作，包括Sprint计划「Sprint Planning」，Scrum每日例会「Daily Scrums」，Sprint评审「Sprint Review」和Sprint回顾「 Sprint Retrospective」，都在Sprint内进行。
在Sprint期间：
·不做任何会危害Sprint目标的变更；
·不降低质量；
·根据需要精细化产品待办事项列表； 以及，
·随着了解到更多信息，与产品负责人阐明和重新协商范围。
Sprint通过确保至少每个日历月对产品目标「Product Goal 」的进度进行检查和适应来实现可预测性。 如果Sprint时间拉的太长，则Sprint目标可能会失效，复杂性可能会增加，风险也可能会增加。 可以采用较短的Sprint来产生更多的学习周期，并将成本和工作投入的风险限制在更短的时间范围内。 每个Sprint都可以视为一个短期的项目。
存在各种方法来预测进度，例如燃尽图，燃起图或累积流图。 尽管都被证明是有用的，但它们并不能取代经验主义的重要性。 在复杂的环境中，将发生什么是未知的。 只有已经发生的事情才可以用于前瞻性决策。
如果Sprint目标过时，Sprint可能会被取消。只有产品负责人有权取消Sprint。
冲刺计划 Sprint Planning
Sprint Planning通过制定Sprint要执行的工作来启动Sprint。最终的计划是由整个Scrum团队的协作创建的。
产品负责人确保与会者准备好讨论最重要的产品待办事项列表目录以及它们如何映射到产品目标。Scrum团队还可以邀请其他人参加Sprint计划，以获取建议。
Sprint Planning涉及以下话题：
话题一：为什么这个Sprint有价值？
产品负责人提出产品如何在当前Sprint中增加价值和效用。然后，整个Scrum团队协作定义一个Sprint目标，以传达当前Sprint对利益相关者有价值的原因。Sprint目标必须在Sprint计划结束前确定。
话题二：这次Sprint能做什么？
通过与产品负责人的讨论，开发成员从产品待办事项列表中选择要添加在当前Sprint中的目录。Scrum团队可以在此过程中细化这些目录，从而增加理解和信心。
选择一个Sprint能完成多少任务可能是个挑战。然而，开发成员越了解他们过去的表现、接下来的能力以及他们的“完成的标准定义”，他们对预测Sprint就越有信心。
话题三：选定的工作将如何完成？
对于每个选定的产品待办事项列表目录，开发成员制定必要工作的计划以创建满足“完成的标准定义”的增量「Increment」。 通常是通过将产品待办事项列表目录分解为一天或更短时间的较小工作目录来完成。 开发成员自行决定如何完成此操作。 没有人告诉他们如何将产品待办事项列表目录转化为价值增量「Increment」。
Sprint目标、为Sprint选择的产品待办事项列表目录以及交付它们的计划一起被称为冲刺期待办事项列表「Sprint Backlog」。
Sprint Planning是有时间限制的，为期一个月的Sprint最多8小时的Sprint Planning。 对于更短的Sprint，时间通常也更短。
Scrum每日例会 Daily Scrum
Scrum每日例会的目的是检查Sprint目标的进度，并根据需要适应冲刺期待办事项列表，调整即将进行的计划工作。
对于Scrum团队的开发成员来说，每日例会是一个15分钟的活动。 为了降低复杂性，它在Sprint每个工作日的同一时间地点进行。 如果产品负责人或Scrum导师正在积极处理冲刺期待办事项列表的目标，那他们将作为开发成员参与其中。
开发成员可以选择他们需要的任何结构和技术，只要他们的每日例会专注于实现Sprint目标进度并为第二天的工作制定可行的计划。 这可以创建专注度并改善自我管理。
每日例会能够改善沟通，识别障碍，促进快速决策，从而消除对其他会议的需求。
每日例会并不是开发成员被允许调整计划的唯一时间。他们经常可以整天见面，详细讨论如何调整或重新规划Sprint的剩余工作。
冲刺评审 Sprint Review
Sprint评审的目的是检查Sprint的结果并确定将来的适应方案。 Scrum团队向主要利益相关者介绍他们的工作成果，并讨论实现产品目标的进度。
期间，Scrum团队和利益相关者将评审Sprint中取得的成就以及环境中发生的变化。 根据这些信息，与会者可以就下一步的工作进行协作。 可能会调整产品待办事项列表来适应新的机遇。 Sprint评审是一个工作会议，Scrum团队应避免将其局限于演示。
Sprint评审是Sprint中倒数第二个事件，为期一个月的Sprint的评审时间限制不超过4小时。对于较短的Sprint，时间也更短。
冲刺回顾Sprint Retrospective
Sprint回顾的目的是规划可以提高质量和效能的方法。
Scrum团队检查最近一个Sprint在有关个人，交互，流程，工具及其“完成的标准定义”的进展情况。 被检查的元素通常随工作领域发生变化。 识别使他们误入歧途的假设，并探究其起源。 Scrum团队讨论Sprint期间进展顺利的事项，遇到的问题以及这些问题是如何解决（或未解决）。
Scrum团队识别最有帮助的改变以提高其效能。 尽早尽快执行影响最大的改进。 甚至可以将它们添加到下一个Sprint的Sprint待办事项列表中。
Sprint回顾结束了Sprint。 为期一个月的Sprint的回顾时间限制不超过3小时。对于较短的Sprint，时间也更短。
Scrum Artifacts
Scrum工件代表工作或价值。 它们旨在最大程度地提高关键信息的透明度。 因此，检查它们的每个人都有相同的基础来适应。
每个工件都包含一项承诺，以确保其提供可提高透明度和专注于可度量的信息：
·对于产品待办事项列表，它是产品目标。
·对于Sprint待办事项列表，它是Sprint的目标。
·对于增量，它是“完成的标准定义”。
这些承诺的存在是为了加强Scrum团队及其利益相关者的经验主义和Scrum价值观。
产品待办事项列表Product Backlog
产品待办事项列表是一个汇集的、有序的列表，列出了改进产品所需的内容。它是Scrum团队所承担工作的唯一来源。
Scrum团队可以在一个Sprint中完成的产品待办事项列表的目录被认为是已经准备好的，可直接移入Sprint Planning事件用来筛选。它们通常在细化活动后获得这种程度的透明度。产品待办事项列表细化是将产品待办事项列表目录分解并进一步定义为更小、更精确目录的行为。这是一项持续进行的活动，用于为产品待办事项列表目录添加详细信息，例如描述、优先顺序和大小。这些属性通常随工作领域而变化。
将要承接这项工作的开发成员负责确定其合适的大小。 产品负责人可以通过帮助开发成员理解和权衡取舍来影响他们。
承诺：产品目标 Commitment: Product Goal
产品目标描述了产品的未来状态，可以作为Scrum团队计划的目标。产品目标在产品待办事项列表中。剩下的产品待办事项列表用于定义实现产品目标将“做什么”。
产品是传递价值的载体。它有明确的边界、已知的利益相关者、定义明确的用户或客户。产品可以是服务，实物，或者更抽象的东西。
产品目标是Scrum团队的长期目标。他们必须先完成（或放弃）一个目标，然后再开始下一个目标。
冲刺期待办事项列表 Sprint Backlog
Sprint待办事项列表由Sprint目标（为什么），为Sprint选择的产品待办事项目录集（做什么）以及交付增量的可行计划（如何做）组成。
Sprint待办事项列表是开发人员制定且执行的计划。 这是开发成员在Sprint期间为实现Sprint目标而计划完成工作的高度可视且实时的成像。 因此，随着了解到更多内容，Sprint待办事项列表会在Sprint的整个过程不断更新。它要有足够的细节，以便他们可以在每日例会中检查自己的进度。
承诺：冲刺目标 Commitment: Sprint Goal
Sprint Goal是冲刺的唯一目标。 尽管Sprint目标是开发人员的承诺，但它为实现此目标所需的确切工作提供了灵活性。 Sprint目标还创造了连贯性和焦点，鼓励Scrum团队一起工作，而不是分开单打独斗。
Sprint Goal是在「Sprint计划事件」期间创建的，然后添加到Sprint待办事项列表中。开发人员在Sprint期间工作时牢记Sprint目标。 如果结果与预期不同，他们将与产品负责人一起，在不影响Sprint目标的情况下，协商此次Sprint中Sprint待办事项列表的范围。
增量Increment
增量是实现产品目标的具体垫脚石。每个增量是所有先前增量的叠加，并经过彻底验证，确保整合的增量能一起有效工作。为了提供价值，增量必须是可用的。
一个Sprint中可以创建多个增量。在Sprint评审中给出增量的总和，从而支持经验主义。但是，增量也可以在Sprint结束之前交付给利益相关者。Sprint评审不应该被视为发布价值的闸门。
只有满足“完成的标准定义”的工作才能被视为是增量的一部分。
承诺：完成的标准定义Commitment: Definition of Done
完成的标准定义是当增量满足产品所需的质量度量时，对增量状态的正式描述。
当产品待办事项列表目录满足完成的标准定义时，就会产生增量。
完成的标准定义通过使每个人都对完成什么工作可以作为增量一部分有共同的理解，来创建透明。如果一个产品待办事项列表目录不符合完成的标准定义，它就不能被发布，甚至不能在Sprint评审中展示。取而代之的是，它会被返回到产品待办事项列表以供将来考虑。
如果增量完成的标准定义是组织标准的一部分，那么所有Scrum团队都必须遵循它。如果不是组织标准，那Scrum团队必须制定一个适合该产品的完成的标准定义。
开发成员必须遵守完成的标准定义。 如果一个产品有多个Scrum团队在一起工作，那他们必须一起定义并遵守相同的“完成的标准定义”。
End Note
Scrum本指南中提供且是免费的。如本文所述，Scrum框架是不变的。虽然只实现Scrum的一部分是可能的，但其结果不是Scrum。Scrum只能以整体存在，如此才可以很好地用作其他技术，方法和实践的容器。
翻译上篇Scrum指南2020版(上)
原文查看The 2020 Scrum GuideTM