Scrum活动
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是规定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。
Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 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 plan meeting
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 待办列表的范围。
二、每日站立会议daily scrum meeting
每日 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 review meeting
Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
对于长度为一个月的 Sprint 来说，评审会议时间最长不超过 4 小时。对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导每位参会者遵守时间盒的规则。
Sprint 评审会议包含以下内容：
- 产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议；
- 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
- 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
- 开发团队演示“完成”的工作并解答关于所交付增量的问题；
- 产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）；
- 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的 Sprint 计划会议提供有价值的输入信息；
- 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；
- 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
四、冲刺回顾会议sprint retrospective meeting
Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。
回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为一个月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。
Scrum Master 确保会议是积极的和富有成效的。 Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员参加该会议。
Sprint 回顾会议的目的在于：
- 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
- 找出并加以排序做得好的和潜在需要改进的主要方面； 同时，制定改进 Scrum 团队工作方式的计划。
Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，如果适用并且不与产品或组织标准相冲突，Scrum 团队计划不同的方式通过改进工作过程或调整“完成”的定义来提高产品质量。
在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和适应的正式机会。
五、待办事项梳理product backlog refinement meeting
产品待办事项通常会很大，也很宽泛，而且想法会变来变去、优先级也会变化，所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容：
- 保持产品待办事项列表有序
- 把看起来不再重要的事项移除或者降级
- 增加或提升涌现出来的或变得更重要的事项
- 将事项分解成更小的事项
- 将事项归并为更大的事项
- 对事项进行估算
产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。
理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。
产品开发决定了，有可能需要其它的技能和输入。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。
