不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。

Scrum的整个过程主要分成五大会议，如下图所示。这些会议均由在这些会议上不具备决策权的ScrumMaster来负责引导。

图1. Scrum流程相关会议

• 待办事项整理会议（Backlog Refinement Meeting）

大多数产品在规划时都是切分为大且模糊的主题，也称史诗级故事（epic）。经验中发现，可以在每个迭代的执行过程中都拿出点时间召开待办事项整理会议，用于为下一个迭代计划会议做准备。在待办事项修整会议上，围绕着产品列表上的主题，产品负责人、Scrum Master和少部分关键开发者，先把功能清单理一理、拆一拆，需要把主题功能拆分为可代表产品特性的多个用户故事。

由产品负责人将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给团队成员，开发团队分析用户故事需要包含哪些技术任务，由Scrum Master建立子任务，方便迭代计划会议的时候团队可以更准确的预估任务故事点。

在会议结束时，产品负责人需要确认会议中提出的需要完善的问题在迭代计划会议开始之前都能被解决，而不浪费迭代计划会议的时间去做这件事情。

图2. 需要大块的史诗故事进行拆分

• 迭代计划会议（Sprint Planning Meeting）

产品负责人建立产品功能清单（Product Backlog），是一组条目化的需求，它必须从客户价值角度描述，并按优先级排序。每个迭代在刚开始的时候，Scrum Master召集相关人员和开发团队一起召开迭代计划会议，讨论在这个迭代中想要把产品的哪些功能清单列为待办事项，并估算本次迭代的工作量。

产品负责人需要讲清楚对于业务来说哪些需求是最重要的，开发团队则负责选定在不积累技术债务的情况下可完成的工作，估算Backlog所需工作量，将工作从“产品清单”中拉入Sprint列表，直到本迭代工作量达到饱和。

产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。由组长协商分发，或队员自行认领任务，独立或与其他成员一起完成任务。

会议时长尽量控制在1-2个小时之内。

图3. Sprint计划会议的交付物是产品功能清单和迭代任务清单

• 每日站会（Daily Scrum）

每天在相同时间相同地点让团队成员们花费15分钟相互沟通进度，每位成员都要总结他昨天做了什么、今天将要做什么、以及是否遇到了阻碍。站着开日会，有利于保持会议简短，如果有额外讨论的话题可以等所有人报告完之后感兴趣的人再继续讨论。Scrum开发团队利用燃尽图来展示整体进度，每天进行简短会面来检验工作进程，并调整后续步骤以确保能如期完成剩余工作。

• 迭代评审会议（Sprint Review）

在Sprint的结尾，产品负责人、Scrum Master、开发团队，可能还有客户一起评审这个迭代的结果。小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈，以用户故事是否能成功交付来评价任务完成情况。未完成的任务会被打回PBI，然后再根据产品负责人的最新优先级顺序判断是否放入后续迭代。任何参与者都可以问问题和提意见，时间控制在1-2个小时之内。

• 迭代回顾会议（Sprint Retrospective）

敏捷开发的一个原则是“可持续的步伐”，迭代之间没有间歇期，团队通常在迭代结束的某个下午召开回顾会议，第二天早上就直接进入下一个迭代计划会议。这是一个简短的反思会，总结哪些事情做得好，哪些事情做的不好。做得好的保留，不好的摒弃。团队中的每个人将在会上反思自己的工作，并决定开始做什么、继续做什么、停止做什么，采取措施以在下一个迭代中做得更好。时间一般控制在15-30分钟。

Scrum是一套开发流程，强调的是自组织、自驱动的，团队只有在实施中不断地仔细体会，采取应对措施来适应自身团队的流程。