敏捷开发项目管理工具 Sprint 0 指南：迭代开始前要准备什么

Sprint 0常被误读为第0个迭代。更准确地说，它是首个正式Sprint开始前的准备期，用来降低启动风险。准备不足时，迭代1容易出现需求理解不一致、测试环境未就绪、Bug无人跟进等问题。对使用敏捷开发项目管理工具的团队来说，Sprint 0的价值是把可执行条件逐项验证。

一、先界定Sprint 0：它不是第0个迭代

1. Sprint 0不在Scrum正式事件中

《Scrum指南（2020版）》把Sprint定义为固定长度、为期一个月或更短的事件，并列出计划会、每日站会、评审会和回顾会四个正式事件。Sprint 0并不在这份框架的正式事件列表里，它是团队实践中的准备阶段。把它当成正式迭代，容易在流程、工时和交付物上产生错位。

2. 它交付的是可执行条件，不是产品增量

正式Sprint结束时，团队要交付有价值、可用的产品增量；Sprint 0结束时，团队交付的是一组可核查的启动条件。判断Sprint 0是否有效，不看开了多少会，而看迭代1能否直接开工。 因此，Sprint 0可以短，可以并行，也可以只补关键缺口。

二、迭代开始前要准备的五类输入

把准备工作按输入分类，比按会议分类更容易检查。五类输入中任何一类缺失，都可能在迭代中放大成返工。

1. 需求输入：用户故事要能验收

需求准备的目标不是把需求写死，而是让团队对做什么、做到什么程度形成共同理解。一个可进入迭代的用户故事，至少要说清角色、目标、价值和验收标准。验收标准写不出来，通常说明需求还没有准备好。 在禅道的需求模块中，用户故事可以拆分、估算、排序和追踪，争议更容易落到具体条目上。

2. 估算输入：承诺要有容量依据

估算是为了暴露不确定性，不是制造精确数字。团队可以用故事点做相对估算，再结合成员可用时间、请假、支持和跨团队依赖，核算可承诺范围。没有容量校准的估算，只是把愿望写进了计划。 多团队协作时，还要提前标出接口、数据和联调依赖。

3. 环境输入：开发到发布链路要跑通

环境准备要覆盖代码库、构建、测试环境、测试数据、账号权限和发布入口。判断环境是否就绪，最直接的方法是让一名开发从提交代码走到测试环境部署，完整跑一遍。 证书、网络策略、第三方接口和回滚路径也要验证。

4. 质量输入：测试策略与Bug闭环要先定

质量准备不是提前写完所有用例，而是先明确测试范围、进入和退出条件、Bug分级规则和回归责任。如果Bug由谁验证、修复后回到哪里都不清楚，迭代越快，返工越难追踪。可以在Sprint 0挑一条主流程做试点，确认链路能走通。

5. 协作输入：角色、节奏和完成定义要对齐

协作准备包括角色分工、会议节奏、看板列、在制品限制和完成定义。完成定义要写成团队能观察的行为，而不是代码写完这类模糊表述。 每日站会看什么、阻塞找谁、变更走什么入口，也要提前说清。

三、把准备结果做成一张检查表

Sprint 0最怕大家都觉得准备好了。把口头判断改成证据检查，争议会少很多。

1. 一项准备对应一个可验证证据

检查表不要只写需求已确认、环境已就绪，而要写清证据在哪里。可验证证据可以是验收标准、容量核算表、环境访问记录、测试策略或完成定义清单。 每项证据指定责任人，并在启动评审时抽查。在敏捷开发项目管理工具中，证据最好能关联需求、任务、Bug和用例，减少跨表核对。

2. 五道门的通过标准

下面这张表把五类输入收束成五道门，便于启动评审时逐项核对。

五道门不是审批关卡，而是风险暴露工具。任何一门未通过，都要先判断它是否会阻断迭代1，再决定补齐、缩小范围还是调整目标。

3. 未通过项怎么处理

未通过项分两类：会阻断主流程的，优先在Sprint 0内解决；不会阻断的，转成迭代1任务，并写清负责人和完成时间。不要把未通过项隐藏成迭代中再说，那等于把风险推迟到交付前。 关键环境或验收标准短期无法补齐时，更稳妥的做法是缩小迭代1范围。

四、Sprint 0开多久，什么时候可以结束

1. 时长由风险决定，不由仪式决定

《Scrum指南（2020版）》建议Scrum团队通常不超过10人。规模化研发中，单个团队规模有限，跨团队依赖却不会自动消失，因此Sprint 0还要把接口人、联调窗口和数据依赖列入风险清单。Sprint 0时长没有统一标准，更可靠的依据是高风险项是否已有验证结果。准备期越长不等于准备越充分，超过必要长度反而会挤占交付反馈。

2. 五个启动信号

出现以下信号，可以认为Sprint 0可以收口：需求有验收标准；承诺范围有容量依据；开发到测试链路跑通；Bug闭环完成一次演练；角色、看板与完成定义达成一致。五个信号都能拿出证据，迭代1才具备可执行的起点。

对使用敏捷开发项目管理工具的团队来说，Sprint 0不是额外负担，而是把迭代1的返工提前暴露。

五、常见问题解答

1. Sprint 0需要全员全程参与吗？

不必全程参与。产品负责人对需求负责，技术负责人对环境负责，测试负责人对质量门负责，其他人按准备项参与。

2. Sprint 0一定要产出完整文档吗？

不必。重点是可核查证据，而不是文档厚度。验收标准、环境清单、测试策略和完成定义够用即可。

3. Sprint 0和需求分析阶段有什么区别？

Sprint 0以启动迭代为目标，允许后续细化；需求分析阶段往往追求一次把范围定清。

4. 团队已经开工，还能补Sprint 0吗？

可以补关键缺口，但不必暂停交付。优先补环境、验收标准和Bug闭环。