很多Scrum团队一开始不知道迭代周期设定多长合适。Scrum要求Sprint在1周到1个月以内的周期，而且一旦选定，Sprint的长度在整个开发过程中保持一致。新的Sprint在上一个Sprint完成之后立即开始。那么到底多长合适呢？
初始设定方法
-
首先，应该选择以周为单位，即：1周，2周，3周，4周，而不是以天为单位，e.g. 7天，12天，22天等。道理很简单，以周为单位方便管理和沟通。以天为单位，大家还得打开日历数天数。这种事务性管理的成本越低越好。
-
其次，对于每个独立交付产品的团队，自己定义Sprint的长度，不要整个公司或部门一刀切；对于一个项目有多个团队协同交付产品的情况，大家保持一个Sprint长度，方便跨团队计划和交付节奏对齐。此外，这样的大项目交付的情况里，每个团队有共同的语言，不至于你说的Sprint1是我团队的Sprint2。
-
再次，选择两周长度的Sprint启动，进行了1个Sprint后, 团队在回顾中讨论，Sprint长度是否合理，是否需要短一些，或者长一些。现在大部分团队的Sprint长度都是两周。为什么要选定两周的长度开始呢？下表列出了不同长度的Sprint的对比：
Sprint不同长度的对比
从上图可以看出，不同的Sprint长度，没有绝对的好或坏。两周Sprint的长度，各个维度处于居中的程度，因此，不必太过于纠结，可以从两周的长度开始，当团队发现一些问题的时候再调整。对于大部分团队，一个Sprint运转后，没有发现需要调整过。
调整迭代实操方法
案例1
某公司刚开展敏捷转型的时候，给每个团队一刀切定为两周。很快在一些团队遇到问题。
一个做互联网产品的团队，每次Sprint进行到中间的时候，经常出现更加紧急业务需求，而把原来规划的需求挤掉。团队跟产品负责人沟通，拒绝Sprint中间调整需求，导致团队与产品负责人关系变得紧张。
这个时候，Scrum master应该与产品负责人分析，这种情况发生的原因是什么。是由于产品负责人的工作没有做好，在Sprint启动前没有准备好需求，到了Sprint执行期间才临时发现需求？还是因为业务变化频繁，两周的Sprint偏长，产品负责人无法提前两周预见需求？如果是业务变化确实比Sprint频繁，可以考虑缩短Sprint周期。但是，要确定这种频繁的业务变化是常态。如果只是临时出现的情况，不需要调整Sprint的长度。
另一个做To B移动端App的团队也发现了问题。他们的移动端发布周期是三周一次，导致他们的Sprint周期与发布周期错位。每次Sprint结束的时候，产品不具备条件发布；而发布的时候，正式下一个Sprint的中期。团队与产品负责人商议，是否需要让发布周期更频繁，而产品负责人认为，对于他们的客户，三周的发布周期完全满足客户的期望，过于频繁反而增加客户的更新成本。因此，团队决定，调整Sprint的周期为三周，Sprint的结束的时候正式发布的时候。
此外，Sprint的长度也取决于团队的工程能力基础。对于那些没有任何自动化集成、自动化测试、自动化部署的“三无”团队，从瀑布转为两周的迭代周期，往往会发现迭代时间结束的时候，产品不具备可交付状态。在这样的情况下，迭代周期是否需要调整呢？
有两个选择：
-
延长迭代周期至3周-4周的长度，在每个迭代计划的时候，将工程能力提升任务纳入Sprint Backlog, 确保每个迭代在交付特性的同时也对工程能力有投资。但是要记住，过了一段时间在工程能力有所提升之后，团队再次回顾迭代周期是否可以缩短。
-
迭代周期不变，调整DoD(完成的定义)，修改为在目前的迭代周期长度下，产品可以达到的程度。要小心的是，采取这个选择必然造成下个迭代在补上个迭代遗留的功课。
案例2：
某大型SaaS互联网软件产品由多个团队协作交付。在两周的迭代周期内，整个产品只能完成特性验证和基本回归验证，如果做全面的回归验证需要再花一周的时间。团队决定修改DoD的条件为:
a. 特性验证通过
b.系统级基本回归验证通过。
但是达到了这个DoD条件还不能发版。团队将系统级全回归验证放到了下一个迭代，在验证通过后发版，因此发版周期错后迭代一周时间。团队将如何缩短验证周期作为改进专项规划。需要注意的是，很多时候，貌似看起来测试周期长是测试的问题，究其根本原因是架构和代码的问题。团队每个迭代做一部分改进工作，直至一个迭代内可以达到发版条件。
由此可见，不管如何抉择，比迭代周期的初始设定更重要的，是团队在遇见问题后思考如何改进，并切实将改进任务纳入到每个迭代中去实施，逐步提升敏捷成熟度，达到迭代结束时产品具备可交付的状态。
不是一定要迭代到永远
迭代不是永远要有的。随着团队的敏捷成熟度的提升，当团队能够每天按需发布，甚至每天可以多次发布，即达到流式开发、持续交付的程度，那时候就可以抛弃迭代周期的约束，而迭代周期只作为团队计划的节奏，不再作为交付的节奏。
