Scrum 框架有足够多的的控制点，使团队在开发过程中能够及时确定和解决问题，并对过程进行调整，以确保不会偏离期望的结果。这些控制点包括 Scrum 的4种仪式、3个工件以及其它活动，它们共同构成了 Scrum 的生命周期。
以下是 Scrum 生命周期的关键步骤：
完整的 Scrum 生命周期始于产品愿景，这个环节并非一个标准仪式，因此常被忽略，但却非常重要。很多卓越的企业都有自己的愿景，它是对企业未來前景和发展方向的高度概括，以反映利益相关者的共同关切。Scrum 同样需要一个愿景来引导 Scrum 团队基于对最终方向的共同理解全力以赴。Scrum 中的产品愿景应符合企业的战略目标，既是对通过开发和部署产品可实现的未来状态的高度概括，也是产品负责人优先考虑构建哪些功能，以什么顺序构建哪些功能，以及不为产品构建哪些功能的有力依据。
好的产品愿景需要回答：
- 产品和所属品类是什么？
- 产品的目标客户是谁，产品将以什么方式为他们解决什么问题或回应什么需求？
- 产品的竞品、可替代品是什么？
- 产品将凭借什么优势、特点超越竞争对手？
- 产品如何服务于企业愿景？
产品愿景出现后，产品负责人需要创建一个产品待办事件列表。所谓产品待办列表，就是产品负责人从各个角度为实现产品愿景所收集的全部需求的集合。产品待办列表是：
- 有序的，即产品负责人需要按需求交付的优先级顺序，将列表中的待办事项一条一条排好；
- 动态的，需求不是在一开始就全都清楚明确的，也不是一成不变的，这就需要产品负责人不断调整列表中所包含的事项及事项排序；
- 可理解的，产品负责人按照需要开发由近及远的顺序，尽可能将列表中的需求事项描述得足够“得体”，让所有开发人员跟他有一致的理解。
接下来，Scrum 团队要一起把 Scrum 的开发过程拆分成若干个 Sprint。Sprint 是 Scrum 的核心，可以视为时间长度固定、有自己目标和计划的“小项目”。当这些小项目被 Scrum 标准仪式、工件串联起来，就能帮助团队遵循“频繁交付可用软件”、“响应计划变化”等敏捷原则。
每个 Sprint 的持续时间不能太短，因为团队需要足够时间交付一个“完成”、可用和潜在可发布的产品增量；当然也不宜过长，否则团队对要完成任务的定义就可能发生改变，对整个产品愿景进度检视的频率也会降低，而复杂性和风险就将随之增加。因此 Sprint 的长度建议为2~4周，并在整个 Scrum 过程中保持一致，前一个 Sprint 结束后，下一个新的 Sprint 立即开始，如此保持高频的交付节奏。固定的 Sprint 时间长度可以帮助团队预测产能，从而更容易制定短期和长期计划，在有规律的节奏中保持高效。Sprint 还是 Scrum 其他标准仪式的容器，它的持续时间决定了其他仪式执行时间的上限。例如，Sprint 为期两周，Sprint 计划会最长不能超过4小时。
当 Sprint 启动的时候，团队通过 Sprint 计划会议（Sprint Planning）讨论接下来的 Sprint 的整体目标是什么，交付的增量中需要包含哪些内容，以及如何完成这些工作。Sprint 的持续时间和开发团队技能配置决定了团队在一个 Sprint 周期内的交付能力，团队从产品待办列表中按优先级拿取符合团队交付能力的需求事项，产品负责人负责介绍清楚这些需求，并同开发团队一起将需求分解成具体的开发任务，形成 Sprint 待办列表（Sprint Backlog）。
Scrum 的方法论中没有任务指派一说，在 Sprint 执行期间，每名开发人员每天从 Sprint 待办列表中领取并完成一定任务。开发团队通过每日站会（Daily Scrum）的形式增进彼此间的交流沟通，检视 Sprint 目标的完成进度和进度趋势，以及发现开发过程中需要移除的障碍。执行 Sprint 的过程中，团队不能做出不利于 Sprint 目标的改变，不能降低质量，随着掌握的相关信息越来越多，产品负责人同开发团队可以进一步澄清或重新协商 Sprint 的工作范围。
当 Sprint 结束时，利用 Sprint 评审会（Sprint Review），开发团队向客户及其他相关方演示和介绍产品增量，重点是做好了什么，而非怎么做的 —— 这并不是一个正式的进度汇报会议，演示增量的目的是为了获取反馈，并同与会者讨论下一步工作安排，也就是为接下来的 Sprint 计划提供有价值的输入信息。
Scrum 强调对于开发过程的定期检视和持续改进，因此在 Sprint 评审会结束之后会安排专门的 Sprint 回顾会（Sprint Retrospective），让整个团队一起聊聊当前 Sprint 的整个过程中，有哪些地方值得肯定，哪些地方需要改进，以及如何改进。基于这个讨论，当进入到下一个 Sprint 时，团队将对他们的敏捷实践有目的地实施一些必要和适当的调整。
团队重复 Step 3~6，通过一个个 Sprint 不断交付增量，直到产品状态达到预期结果。在此期间，产品负责人还要牵头开展一项可以随时开展的工作 —— 产品待办列表精化（Product Backlog Refinement/Grooming）。
我们在前面讲过，产品待办列表是动态的，这就意味着随着开发推进、产品投入使用和获得更多的市场反馈，产品待办列表中的事项可能会被重新评估、修改和调整排序，优先级靠前的事项必须包含足够多的细节，以使估算更为可靠，满足后续 Sprint 的“准入”标准。