很多团队一开始不知道对Sprint设置多长是合适的。Scrum要求一个Sprint在1周或1个月以内，而且一旦选定，Sprint的长度在一个周期内将保持不变。新的Sprint在上一个Sprint结束之后立即开始。

那么对Sprint到底设置多长合适呢？

• 首先，应该选择以周为单位，即1周、2周、3周、4周；而不是以天为单位，如7天、12天、22天等。道理很简单，以周为单位方便管理和沟通；而以天为单位，大家还得打开日历数天数。这种事务性管理的成本越低越好。
• 其次，对于每个独立交付产品的团队，最好单独定义Sprint的长度，而不是整个公司或部门“一刀切”。对于一个项目有多个团队协同交付产品的情况，大家要保持同样的Sprint长度，这样既方便跨团队计划和对齐交付节奏，也让每个团队有共同的语言。
• 最后，第一个Sprint运行结束后，团队可以在Sprint回顾中讨论Sprint长度是否合理，是否需要调整。
  

现在使用2周长度的Sprint的团队比较多。为什么大家喜欢选择2周的长度呢？表6-2对不同长度的Sprint进行了对比。

表6-2不同长度的Sprint

从表6-2可以看出，不同的Sprint长度，没有绝对的好与坏。由于2周的Sprint长度在各个维度处于居中的位置，所以相对而言，选择此长度，更利于团队即时发现问题并对Sprint长度进行再调整。

公司N刚开展敏捷转型的时候，所有团队都被“一刀切”为2周的Sprint长度。不久，一些团队遇到了问题。一个做互联网ToC产品的团队，经常在Sprint进行到中间的时候出现更加紧急的业务需求，于是把Sprint原来计划的需求挤掉了。团队跟产品负责人沟通，拒绝在Sprint期间调整需求，结果导致团队与产品负责人的关系变得紧张。

在这种情况下，ScrumMaster应该引导团队与产品负责人一起分析：这种情况发生的原因是什么？是由于产品负责人的工作没有做好，在Sprint启动前没有准备好需求，到了Sprint执行期间才临时发现需求；还是由于业务变化频繁，产品负责人无法提前2周预见需求？如果是业务变化频繁，可以考虑缩短Sprint周期。但是，要确定这种频繁的业务变化是否是常态，如果只是临时出现的情况，则不需要调整Sprint的长度。

公司N中另一个做ToB移动端App的团队也遇到了Sprint周期的问题。他们的发布周期是3周一次，而公司给团队定的Sprint周期是2周，导致他们的Sprint周期与发布周期错位。每次Sprint结束的时候，产品不具备发布条件；而发布的时候正处于下一个Sprint的中期。于是团队与产品负责人商议，是否需要让发布周期更频繁，而产品负责人认为，对于他们的客户来说，3周的发布周期完全足够，过于频繁反而增加客户版本更新的成本。因此，团队决定，调整Sprint的周期为3周，将Sprint周期与发布周期保持一致。

Sprint长度也取决于团队的工程能力。对于那些没有任何自动化集成、自动化测试、自动化部署的“三无”团队，从瀑布研发方式转为2周的迭代周期后，往往会发现在迭代结束的时候产品处于不可交付的状态。在这种情况下，迭代周期是否需要调整呢？团队可以有两个选择。

• 延长迭代周期至3~4周。在计划每个迭代周期的时候，将工程实践的任务纳入SprintBacklog，确保每个迭代在交付特性的同时，团队的工程能力能够得到提升。但是要记住，过了一段时间，团队的工程能力有所提升之后，团队需再次回顾并判断迭代周期是否可以缩短。
• 保持迭代周期不变，调整DoD，将其修改为在目前的迭代周期下产品可以达到的程度。但是需要小心的是，这样做必然会造成下一个迭代的工作加重。
  

一家做SaaS的公司P，其互联网软件产品由多个团队协作交付。在2周的迭代周期内，团队只能完成产品的特性验证和基本回归验证，如果做系统级全量回归验证需要再花1周的时间。于是团队决定修改DoD的条件为：

• 特性验证通过；
• 系统级基本回归验证通过。
  

但是达到了这个DoD的条件还不能发版，因为团队将系统级全量回归验证放到了下一个迭代，在其验证通过后才能发版，因此发版周期错后迭代1周的时间。该团队将缩短验证周期作为改进专项，每个迭代做一部分专项工作，直至2周之内达到发版条件。

由此可见，不管如何抉择，比迭代周期的初始设定更为重要的是团队在遇见问题后如何应对和改进，并切实将改进任务纳入每个迭代中去实施，逐步达到迭代结束时产品应具备的可交付状态。

最后，需要特别强调的是，迭代不是永远都要有的。随着团队敏捷成熟度的提升，当团队能够按需发布，甚至每天可以多次发布，即达到流式开发、持续交付的程度，那时候就可以抛弃迭代周期的框架，迭代的长度可以只作为团队计划的节奏，不再作为交付的节奏。

很多团队一开始不知道对Sprint设置多长是合适的。Scrum要求一个Sprint在1周或1个月以内，而且一旦选定，Sprint的长度在一个周期内将保持不变。新的Sprint在上一个Sprint结束之后立即开始。

那么对Sprint到底设置多长合适呢？

• 首先，应该选择以周为单位，即1周、2周、3周、4周；而不是以天为单位，如7天、12天、22天等。道理很简单，以周为单位方便管理和沟通；而以天为单位，大家还得打开日历数天数。这种事务性管理的成本越低越好。
• 其次，对于每个独立交付产品的团队，最好单独定义Sprint的长度，而不是整个公司或部门“一刀切”。对于一个项目有多个团队协同交付产品的情况，大家要保持同样的Sprint长度，这样既方便跨团队计划和对齐交付节奏，也让每个团队有共同的语言。
• 最后，第一个Sprint运行结束后，团队可以在Sprint回顾中讨论Sprint长度是否合理，是否需要调整。
  

现在使用2周长度的Sprint的团队比较多。为什么大家喜欢选择2周的长度呢？表6-2对不同长度的Sprint进行了对比。

表6-2不同长度的Sprint

从表6-2可以看出，不同的Sprint长度，没有绝对的好与坏。由于2周的Sprint长度在各个维度处于居中的位置，所以相对而言，选择此长度，更利于团队即时发现问题并对Sprint长度进行再调整。

公司N刚开展敏捷转型的时候，所有团队都被“一刀切”为2周的Sprint长度。不久，一些团队遇到了问题。一个做互联网ToC产品的团队，经常在Sprint进行到中间的时候出现更加紧急的业务需求，于是把Sprint原来计划的需求挤掉了。团队跟产品负责人沟通，拒绝在Sprint期间调整需求，结果导致团队与产品负责人的关系变得紧张。

在这种情况下，ScrumMaster应该引导团队与产品负责人一起分析：这种情况发生的原因是什么？是由于产品负责人的工作没有做好，在Sprint启动前没有准备好需求，到了Sprint执行期间才临时发现需求；还是由于业务变化频繁，产品负责人无法提前2周预见需求？如果是业务变化频繁，可以考虑缩短Sprint周期。但是，要确定这种频繁的业务变化是否是常态，如果只是临时出现的情况，则不需要调整Sprint的长度。

公司N中另一个做ToB移动端App的团队也遇到了Sprint周期的问题。他们的发布周期是3周一次，而公司给团队定的Sprint周期是2周，导致他们的Sprint周期与发布周期错位。每次Sprint结束的时候，产品不具备发布条件；而发布的时候正处于下一个Sprint的中期。于是团队与产品负责人商议，是否需要让发布周期更频繁，而产品负责人认为，对于他们的客户来说，3周的发布周期完全足够，过于频繁反而增加客户版本更新的成本。因此，团队决定，调整Sprint的周期为3周，将Sprint周期与发布周期保持一致。

Sprint长度也取决于团队的工程能力。对于那些没有任何自动化集成、自动化测试、自动化部署的“三无”团队，从瀑布研发方式转为2周的迭代周期后，往往会发现在迭代结束的时候产品处于不可交付的状态。在这种情况下，迭代周期是否需要调整呢？团队可以有两个选择。

• 延长迭代周期至3~4周。在计划每个迭代周期的时候，将工程实践的任务纳入SprintBacklog，确保每个迭代在交付特性的同时，团队的工程能力能够得到提升。但是要记住，过了一段时间，团队的工程能力有所提升之后，团队需再次回顾并判断迭代周期是否可以缩短。
• 保持迭代周期不变，调整DoD，将其修改为在目前的迭代周期下产品可以达到的程度。但是需要小心的是，这样做必然会造成下一个迭代的工作加重。
  

一家做SaaS的公司P，其互联网软件产品由多个团队协作交付。在2周的迭代周期内，团队只能完成产品的特性验证和基本回归验证，如果做系统级全量回归验证需要再花1周的时间。于是团队决定修改DoD的条件为：

• 特性验证通过；
• 系统级基本回归验证通过。
  

但是达到了这个DoD的条件还不能发版，因为团队将系统级全量回归验证放到了下一个迭代，在其验证通过后才能发版，因此发版周期错后迭代1周的时间。该团队将缩短验证周期作为改进专项，每个迭代做一部分专项工作，直至2周之内达到发版条件。

由此可见，不管如何抉择，比迭代周期的初始设定更为重要的是团队在遇见问题后如何应对和改进，并切实将改进任务纳入每个迭代中去实施，逐步达到迭代结束时产品应具备的可交付状态。

最后，需要特别强调的是，迭代不是永远都要有的。随着团队敏捷成熟度的提升，当团队能够按需发布，甚至每天可以多次发布，即达到流式开发、持续交付的程度，那时候就可以抛弃迭代周期的框架，迭代的长度可以只作为团队计划的节奏，不再作为交付的节奏。