使用Scrum的组织通常会使用30天作为Sprint的长度，但是Scrum同样允许周期更短的Sprint。周期较长的Sprint通常用于变化较少的环境，而周期较短的Sprint则通常用于机会较多或者更具有挑战的多变环境。 根据以下这些方面可以评估出最合适你的项目的Sprint长度：
-
使用时间较短Sprint的代价
-
更大的灵活性和控制力
-
项目的长度
使用较短Sprint的理由
使用个为期1周的Sprint比1个为期30天的Sprint拥有更大的灵活度和控制力。下面这些原因也许会影响你对Sprint长度的选择：
-
不稳定的市场环境：Sprint的长度决定了你能够重新为产品制定目标和计划的频率。当产品所针对的是新兴或者是变化频繁的市场时，你希望可以拥有更大的灵活性，从而能够更快地适应各种随时出现的机会。又或者你不希望在有机会改变 产品的方向之前对某项特性投入过大。
-
不稳定的团队：Scrum团队有时需要长达一年的时间才能完成磨合，也有可能他们根本无法做到。这时，较短的Sprint能够让每个人都更清晰地了解团队的动态，从而快速地解决出现的问题、提高生产率。
-
不确定的技术方案：每当要使用新的技术，就需要更早地了解新技术相关的使用方法及其能够带来的价值。在新的产品中，新技术是否可用往往是整个产品成败的关键。因此，我们需要在大范围使用新技术之前先开发小的功能模块，以评估其是否可用。
-
需要确定团队的速率：对一个项目的成本进行预测的最佳方法就是参照以前做过的类似项目，例如使用过相同的技术和长期合作的团队。如果没有类似的项目可供参考，那么备选方案就是进行几个周期较短的Sprint。随着团队成员合作时间的增加以及对项目所属领域和所用技术的了解的深 入，团队就能够开始形成一个比较稳定的速率，也就是说每个Sprint能够完成的功能数量趋于稳定。
-
提供学习的经历：人们都喜欢成功。当人们想要学习骑自行车、溜冰或者滑雪的时候，他们通常会先尝试一小段时间，然后总结失败的经验教训并作出改变，再继续尝试。同理，较短周期的Sprint正是提供了这种学习体验。
-
需要风险控制：有时你所期望的项目回报也许是无法达到的。当市场非常不稳定或者未知因素太多，使用的技术未知是否可行，团队成 员都是初来乍到时，尽快收集项目的成本和回报的信息是非常重要的，而短周期的Sprint则正好提供了这样的信息。
使用较长Sprint的理由
两个为期2周Sprint比1个为期30天的Sprint的成本更高。因为在此期间，你需要进行双倍的Sprint计划会议、回顾会议以及评审会议。Scrum团队不得不比平时花费多1倍的精力进行设计。Sprint使团队达到最佳效率所需的时间也会比平时多一倍。
使用较短周期的Sprint的代价就是要花费更多时间在计划和回顾会议上。你可以把这种成本看作机会成本或者保障成本。图6.6展现了不同长度的 Sprint用于会议的时间。例如，在30天内，长度分别为1周、2周和30天的Sprint进行会议所需要的时间。这里所说的Sprint会议包括计划 会议、回顾会议和评审会议。因为每日例会所需要的时间是相等的，因此在这里不进行比较。在本例中，Scrum团队进行一个为期30天的Sprint所需要 的成本是20万美元. 有时候，由于需要更好的可预测性、更强的控制力和更大的灵活性，因此很多组织认为短周期的Sprint所带来的额外花销仍然是可以接受的。
不要尝试这些长度的Sprint
当Sprint的长度短于一周时，团队通常无法将需求转化成可用的功能。开发团队发现在如此短的时间内要开发出可用的功能或者为管理层提供有用的信息是非常困难的。
我们推荐Sprint的长度应该不长于30天或者一个月。当Sprint的长度超出30天（或者一个月）时，有可能会发生以下这些问题：
1. 相关负责人会失去对项目的专注，甚至忘记了项目的相关内容。
2. 随着需求数量的增加，项目的整体复杂度就会以超过线性的增长方式增加。为了管理增加的复杂度以及记录之前作出的决定，开发团队需要更多文档和设计。
3. Scrum提倡的短时间会议让团队很难在查看了大量的信息之后，吸收这些信息并作出决定。
