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 plan meeting
Sprint中要做的工作在Sprint计划会议中来做计划。这份工作计划是由整个Scrum团队共同协作完成的。
Sprint计划会议是限时的，以一个月的Sprint来说最多8小时为上限。对于较短的Sprint，会议时间通常会缩短。Scrum Master要确保会议顺利举行，并且每个参会者都理解会议的目的。Scrum Master要教导Scrum团队遵守时间盒的规则。
Sprint计划会议回答以下问题：
接下来的Sprint交付的增量中要包含什么内容？要如何完成交付增量所需的工作？
话题一：这次Sprint能做什么？
开发团队预测在这次Sprint中要开发的功能。产品负责人讲解Sprint的目标以及达成该目标所需要完成的产品待办列表项。整个Scrum团队协同工作来理解Sprint的工作。
Srint会议的输入时产品待办列表、最新的产品增量、开发团队在这个Sprint中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的Sprint可以完成什么工作。
在Sprint计划会议中，Scrum团队还草拟了一个Sprint目标。Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。
话题二：如何完成所选的工作？
在设定了Sprint目标并选出这个Sprint要完成的产品待办列表项之后，开发团队将决定如何在Sprint中把这些功能构建成“完成”的产品增量。这个Sprint中所炫出的产品待办列表项加上交付它们的计划称之为Sprint待办列表。
开发团队通常从设计整个系统开始，到如何将产品待办列表转换成科工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量，然而，在Sprint计划会议中，开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的Sprint中能够完成。在Sprint计划会议的最后，开发团队规划出在Sprint最初几天内所要做的工作，通常以一天或者更少为一个单位。开发团队自组织地领取Sprint待办产品列表中的工作，领取工作在Sprint计划会议和Sprint期间按需进行。
产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。如果开发团队认为工作过多或者过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或者领域知识方面的建议。
在Spring计划会议结束时，开发团队应该能够像产品负责人和Scrum Master解释他们将如何以自组织团队的形式完成Sprint目标并开发出预期的产品增量。
Sprint目标
Sprint目标是在当前Sprint通过实现产品待办列表要达到的目的，它为开发团队提供指引，使得团队明确为什么要构建增量。Sprint目标在Spring计划会议中确定。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内完成每一个事项。每个人都需要清楚预期产出是什么。
产品开发决定了，哟可能需要其他的技能和输入。因此，产品待办事项列表梳理最好是所有团队成员都参与的活动，而不单单是产品负责人。
