Sprint是Scrum框架里固定时长的迭代周期，通常为1～4周。ScrumSprint流程不是几场零散的会议，而是一条从规划到回顾的完整链路：规划会定目标，每日站会同步进度，评审会交付增量，回顾会沉淀改进。下面按时间顺序拆解每个环节的做法与常见问题，团队可以直接照着把下一个迭代跑顺。
Sprint流程概览：一个迭代周期怎么运转
一个Sprint从规划会开始，到回顾会结束，四个活动各司其职。下表列出每个环节的核心目标、参与人和建议时长，便于团队安排节奏。
| 环节 | 核心目标 | 参与人 | 建议时长 |
|---|---|---|---|
| Sprint规划会议 | 确定迭代目标与待办范围 | 产品负责人、开发团队、Scrum Master | 两周迭代约2小时 |
| 每日站会 | 同步进度、暴露阻碍 | 开发团队，Scrum Master引导 | 不超过15分钟 |
| Sprint评审 | 演示增量、收集反馈 | 产品负责人、干系人、开发团队 | 两周迭代约1.5小时 |
| Sprint回顾 | 复盘过程、制定改进行动 | 开发团队、Scrum Master | 两周迭代约1.5小时 |
前两个环节属于"计划与执行"，后两个属于"检视与调整"。建议时长会随迭代长度等比伸缩，迭代越长，各会议的时间盒相应拉长。
Sprint规划会议：确定迭代目标与范围
规划会在每个Sprint开始时召开，目标只有一个：让团队清楚这个迭代交付什么、怎么交付。会议结束前，团队要能回答三个问题：Sprint目标是什么、从产品待办列表选哪些条目、每条如何落地。
规划前要有两个前置条件。一是产品待办列表已按优先级梳理好，产品负责人能讲清每条需求的验收标准；二是团队对历史迭代速度有基本判断，知道一个周期能承接多少工作量。
会议分两步走。第一步，产品负责人介绍本期需求，说明业务背景和验收标准，团队成员提问、澄清边界。第二步，团队一起评估工作量，把需求拆成可执行的任务，形成迭代待办列表，并敲定Sprint目标。
规划会最常见的错是贪多。团队把产品待办列表前十条全排进迭代，结果后半段整体积压。比较稳妥的做法，是只承诺有把握完成的部分，把余量留给突发问题。规划会上敲定的迭代待办列表，可以直接落到禅道的「执行」里：需求关联进来、任务分解指派，后续站会和评审都有据可查。
每日站会：让进度透明、及时暴露阻碍
每日站会是Sprint执行期的固定节拍，每天同一时间、同一地点站立进行，控制在15分钟内。它存在的意义不是汇报，而是让全团队对当前进度和阻碍有一致的认知。
每个成员围绕三个问题发言：昨天完成了什么、今天准备做什么、有没有阻碍。发言要具体，直接说任务名称或编号，避免"正在做某模块"这类模糊表述。
站会不是解决会。一旦有人开始深入讨论技术方案，Scrum Master要及时打断，把深讨论留到会后，只保留相关成员。团队围绕迭代任务列表过一遍状态，谁的任务被阻塞、谁在等别人的交付，一眼就能看清。
这里有一个常见的反模式：站会变成向上汇报的进度会，成员对着Scrum Master或产品负责人逐条汇报，其他人不参与。站会应该是团队成员之间的同步，不是汇报，讨论留在会后，别让同步占满整个上午。
Sprint评审：面向干系人交付可验收增量
Sprint评审是Scrum Sprint流程中面向外部的交付环节，在迭代末尾举行，核心是演示已完成、可运行的产品增量，而不是介绍进度。产品负责人和干系人现场查看、提出反馈，团队据此判断哪些条目达到"完成"的标准。
评审会的主角是增量本身。团队把做出来的功能实际演示一遍，说明它解决了什么问题、与验收标准还差多少。干系人基于真实交付提意见，这些反馈进入产品待办列表，参与下一个迭代的排序。
未完成的条目不会自动带入下个迭代。评审结束后，团队把未完成项和新增需求一起放回产品待办列表，在下一个规划会上重新评估优先级与工作量。评审的产出，是被更新过的产品待办列表。
评审会最怕变成PPT汇报。团队放几十页幻灯片讲"做了什么"，干系人却看不到可运行的东西，反馈自然流于表面。坚持现场演示，哪怕只完成一两个功能，也比空谈有价值。
Sprint回顾：复盘过程、沉淀改进行动
回顾会在评审会之后、下个规划会之前举行，主题从"交付了什么"转向"团队怎么协作"。团队一起复盘协作方式、流程和工具，找出哪里顺畅、哪里卡顿，并定出改进行动。
一场有效的回顾围绕三个问题展开：哪些做法效果好要保留；哪些拖累团队要调整；哪些问题影响了满意度和交付效率。讨论结果要落到具体行动，明确负责人和时间点，而不是一句"下次注意"。
回顾会和评审会容易混淆。评审会面向外部干系人，关注产品增量；回顾会面向团队内部，关注协作过程。前者改产品，后者改流程，两个都要开，顺序不能颠倒。
即便团队运行得很顺，也要定期检视，把好做法固化、把坏习惯改掉。改进行动进入下一个迭代的待办列表继续跟踪，上一轮没做完的，下一轮回顾先核一遍，改进才能形成闭环。
常见误区与避坑清单
结合团队实践，下面几个误区最常拖累Scrum Sprint流程：
- 规划会贪多，排入过多需求，导致迭代后半段积压、目标失真。
- 站会开成汇报会或讨论会，前者没有信息增量，后者占用全员时间。
- Sprint中途随意加需求，破坏迭代承诺，紧急问题应记录后进下一个迭代评估。
- 评审只讲不演示，干系人看不到增量，反馈无从谈起。
- 回顾流于形式，复盘完不落行动项，或行动项无人跟进。
常见问题解答FAQ
Sprint时长一般设多长？
常见的是两周。刚引入Scrum的团队可以从两周起步，节奏适中，反馈周期不短。成熟后可缩短到一周，或按业务节奏调到三到四周，关键是时长保持稳定。
每日站会需要产品负责人参加吗？
建议参加。产品负责人能听到进展和阻碍，及时澄清需求。但站会的主场是开发团队，产品负责人以倾听和必要澄清为主，不在会上派活。
Sprint中途需求变多了怎么办？
不要直接塞进当前迭代。先记入产品待办列表并评估优先级，影响确实很大的，由团队和产品负责人共同决定是否调整本轮范围，而不是单方面加需求。
Sprint评审一定要演示吗？
一定要。评审的价值在于让干系人看到可运行的增量并给反馈，只讲进度不演示，评审就退化成了汇报会，失去检视产品的意义。
**回顾会的行动项如何落地？****把行动项变成可跟踪的任务，明确负责人和截止时间，进入下一个迭代的待办列表。下一轮回顾先核对完成情况，未完成的继续跟进。