时间箱机制是Scrum的一个非常重要的方面。在Scrum框架中有六个时间箱。
时间箱一：Sprint
Sprint的本意是指冲刺，在Scrum中，一个Sprint就是一个迭代，Sprint长度通常2-4周，它是一个时间箱，在项目进行过程中不允许延长或缩短Sprint长度。在Sprint中，ScrumMaster要确保没有任何影响Sprint目标的变更发生。团队构成和质量目标在Sprint中均保持不变。Sprint由Sprint计划会议、开发工作(需求分析、设计、开发、测试、质量控制等)、每日站会、Sprint评审会议和Sprint回顾会议等活动组成。Sprint一个紧跟一个进行，之间没有任何时间间隔。
其它的5个时间箱对应Scrum的5个仪式：
时间箱二：发布计划会议（Release Planning Meeting）
发布计划会议的目的是建立Scrum团队以及组织内的其他部门能够理解和沟通的计划和目标。发布计划会议需要回答以下两个问题：“我们如何以最佳方式将愿景转化为成功的产品？我们怎样才能达到或甚至超越客户的满意度和投资回报？”发布计划确定发布目标、具有最高优先级的产品Backlog条目、重大风险和发布所包含的全部特性和功能。另外， 发布计划会议确立大致交付日期和费用，如果没有任何变化就应当保持该日期和费用。组织可以检视开发进程，以每个Sprint为基础调整发布计划。
发布计划会议是完全是可选的。如果项目开始的时候没有这个会议，那么这些工件的缺少将成为一个需要被移除的障碍，解决这个障碍便成为了产品Backlog中的一个条目。
Scrum以迭代的方式构建产品，每个Sprint中都会交付产品增量，通常价值最高、风险最大的部分先开发。产品增量随着Sprint交替而完成，每个增量都是整个产品的可交付一部分。当创造出足够多的有价值的、可供投资方使用的产品增量时，产品就可以发布了。
大多数组织已经有自己的发布计划过程，并且在大多数过程中的大部分计划已经在发布之初完成，而且也不会更改。在Scrum发布计划会议上确立一个整体目标和预期结果。发布计划会议通常不超过组织构建传统发布计划的15-20%时间。然而，Scrum发布在每个Sprint评审和计划会议上都执行准时（Just-in-time）计划，同时，在每日站会上执行每日准时（Just-in-time）计划。总的看来，Scrum发布可能比传统的发布计划耗费略多的工作。
发布计划会议需要为该发布做产品Backlog条目的估算和优先级排列。
时间箱三：Sprint计划会议（Sprint Planning Meeting）
Sprint计划会议的产物是Sprint Backlog。对于一个月为周期的Sprint，计划会议的时间箱限定为8小时。对于较短的Sprint，计划会议一般安排整个Sprint周期的5%时间。Sprint计划会议的内容包括以下两个部分：第一部分，4小时的时间箱中需要确定该Sprint将要完成什么任务。第二部分，也是4小时的时间箱，团队研究在Sprint内如何构建产品增量。
Sprint计划会议包含两部分内容：“做什么”和“怎么做”。一些Scrum团队将这两部分结合起来。第一部分，Scrum团队处理“做什么”的问题。产品负责人给团队介绍最高优先级的产品Backlog条目，并一起决定接下来的Sprint中开发什么功能。Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择多少产品Backlog的条目，因为只有团队可以评估在接下来的Sprint内可以完成什么工作。
选定产品Backlog条目后，Sprint目标也就明确了。Sprint目标通过实现产品Backlog的条目来达到。Sprint目标为团队提供指导，使团队明确构建的产品增量的目的。Sprint目标是发布目标的子集。
确定Sprint目标的原因是在功能方面为团队留出一定的回旋余地。例如，上一个Sprint的目标可能是：“通过一种安全、可重获的交易中间件实现客户账户修改功能的自动化”。所以当团队工作时，就会紧记这个目标。为了达到这个目标，团队就需要实现该功能和技术。如果团队感觉实现过程比预期的难度大，那么就可以和产品负责人协商，只实现部分功能。
在Sprint计划会议的第二部分，团队需要处理“怎么做”的问题。在Sprint计划会议的第二个4小时时间箱中，团队需要弄清楚如何将“做什么”会议阶段选定的产品Backlog条目转化成完成的增量。通常团队会先以设计展开工作，设计过程中，团队确定任务，这些任务就是将产品Backlog转化成可用软件的具体工作。任务需要被分解，以便在一天之内完成。这个任务列表就是SprintBacklog。团队通过自组织，并且是自己认领的方式分担任务，任务认领可以在Sprint计划会议上进行，或也可以Sprint中及时（Just-in-time）确定。
通常，Sprint计划会议上只设计出SprintBacklog的60- 70%。剩余部分后续完成，或者给出大体的估算并在Sprint中再分解。
产品负责人会参加Sprint计划会议的第二部分，为团队讲解产品Backlog条目，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商、确定产品Backlog。团队也可以邀请其他人员参加会议，以寻求技术和领域建议。新组建的团队常常在这次会议中第一次意识到：整个团队要么一起成功，要么一起失败，没有个体这个概念。团队同时认识到必须依靠自己。正因为意识到这一点，整个团队才逐渐自组织并形成自己的特色，真正成为一个团队。
时间箱四：每日站会（Daily Scrum Meeting）
团队每天15分钟的检视和调整会议称之为每日站会。每日站会在各个Sprint都是在同一时间，同一地点进行，因为会议时间很短，通常，会议都是站立进行的。会议上，每个团队成员需要回答以下三个问题：
从上次会议到现在都完成了哪些工作？
下次每日站会之前准备完成什么？
工作中遇到了哪些障碍？
每日站会可以增强交流沟通、省略其他会议、确定并排除开发遇到的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。
ScrumMaster要确保团队举行每日站会，团队则负责召开会议。ScrumMaster指导团队执行规则来控制会议时间，并保证团队成员进行简短有效的汇报。ScrumMaster也要确保“鸡” 的角色不允许在会议上发言或以各种方式干扰会议。
每日站会不是进度汇报会议。这个会议是为那些将产品Backlog条目转化成为产品增量的人（ 团队）召开的。团队承诺实现Sprint目标和完成产品Backlog条目，每日站会对Sprint目标的进展的检视（三个问题）。紧随每日站会之后的一些解决问题的会议通常是对Sprint中的下一步工作进行调整，目的在于增加团队实现目标的可能性。这是Scrum经验过程中的重要检视和调整的会议。
时间箱五：Sprint评审会（Sprint Review Meeting）
Sprint结束时要举行Sprint评审会议，一个月的Sprint通常对应时长4小时Sprint评审会议。对于时间少于一个月的Sprint来说，该会议的时长不要超过整个Sprint的5%。
Sprint评审会议中，Scrum团队和利益干系人沟通Sprint中完成了哪些工作。然后，根据完成情况和Sprint期间产品Backlog的变化，他们确定接下来的工作。这是一个非正式会议，会议中进行功能演示，以促进下一步工作的互助与合作。
评审会议至少要包含以下因素：产品负责人确定完成了哪些工作和剩余哪些工作。团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。然后，团队演示完成的工作并答疑。产品负责人和与会人员讨论产品Backlog，并根据不同的速率计划出可能的完成日期。接着，整个团体就哪些工作已经完成，同时这对下一步工作有何意义进行探讨。Sprint评审会议为接下来的Sprint计划会议提供了宝贵的参考信息。
时间箱六：Sprint 回顾会议（Sprint RetrospectiveMeeting）
在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint，回顾会议的长度一般为3小时，在会议上，ScrumMaster鼓励团队在Scrum过程框架和时间的范围内，对自己的开发过程进行改进，使下一个Sprint的效率更高、工作更容易。许多书籍都介绍了召开回顾会议的技巧。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的，和那些如果采用不同方法可以取得更好效果的条目。这些包括：Scrum团队、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。在Sprint回顾会议的最后，Scrum团队应该确定将要在下个Sprint中实现的有效改进方法。这些变化更适应于经验检验。
