我们的项目是在一个分布式的环境下展开的——开发团队和产品管理处在不同的地理位置。当我们第一次进入到这个项目的时候时，我们要做的是帮助一个已经存在了数年的随机开发项目，没有固定的迭代和发布计划，建立离岸的开发中心。它的业务并不复杂，但是代码质量低下，再有就是它的知识持有人不在场出现（或者远程操作）令项目启动比我们以及项目干系人所预期的要难得多。
我们用最开始的三到四个月时间学习代码库（通过修复漏洞和增加新的功能）。最后，我们已经清楚了要如何来做我们的项目。 我们知道我们想试一个敏捷方法，在许多讨论论辩之后，我们决定试 Scrum （这里的来龙去脉，Scrum之前是如何被介绍的，那么本来应该怎么介绍它，它是如何最终改变了公司运作的方式是我们另外一篇或者两篇文章的主题——也许是下次）。
Scrum起航
我们刚刚开始的时候，我们选择用四周的sprint。我们的产品backlog方面，我们使用per-feature需求文档，我们称这个为feature specs。每一个feature的规格说明通常是一本三到五页的文档，里面包括特征描述，主要工作流以及截图。我们的特征规格是由产品经理远程制作的。
这些文件在一定程度上是有作用的。尽管这样， 时常需要收集下一个sprint所必需的一定量的规格让产品负责人很累。他和产品经理经常拼命去找时间来写规格。甚至有的时候，哪怕他们已经写下了这些规格，这种情况经常时有发生，他们所提供的信息不足以让开发人员来做出合理的估计。
团队觉得Sprints长度没有问题，但是管理团队认为他们需要更可视化的结果。 同时，我们想是否更短的sprint会帮助我们的团队专注，同时优化绩效。我们计划切换到尽可能最短的期限：仅仅一周。如果不成功的话，我们随时可以切换回来。
我们的部分改变带来了积极的结果。比方说，股东每周能收到更可视化的结果。尽管如此，但实际上是弊远大于利。第一，开发团队需要每周 deliver，他们开始感觉有压力。第二，要在一周时间以内提供有价值的功能有的时候是很有难度的。最后，启动和终结一个sprint的成本感觉很高，不管是团队时间方面的投入还是情感上的投入。
前面路还远，我们还不能休息
一周的sprints的结果很不如人意，我们决定还是返回到四周的sprints。
同我们之前所经历的很仓促的每周发布相比，接下来的一个月将会感觉很轻松。 因为我们开始调整进程到我们理想的样子（我们期望达到现实）我们努力开始提前收集规格，给项目人员和测试人员提供更多详细的说明。事情会有所改善的。尽管这样，当我们认真仔细地看我们的sprint 活动，我们意识到我们实际上在做的是三周 sprints加上一周最后未完成的sprint任务缓冲，而非四周sprint。这可真不是我们期望“我们的 Scrum”的样子。
喂！ 我看到陆地了
自这个项目被外包至今已经超过一年了。事情得到了改善，但还没有达到我们期待的效果。在那时，我们对要求管理过程做了一个根本的改变：我们用轻量的用户故事 (受Mike Cohn的 《应用用户故事》的启发) 取代了我们的中级重量的规格说明书。
如我们希望的一样，用户故事在开发和产品经理之间的沟通得以提高。同时他们帮助团队增加了对于业务需要的理解。所以，公司内部的的信任和沟通得以提高。这个相应地提高了产品质量（产品质量的提高也得益于更细致的用户故事使得计划更加优化 ，增加的单元测试量以及增加的测试团队规模）。
达到先前所说的条件之后，我们计划试试更短的sprints。 以下的是我们要抓住的“野兔”，他们是曾被认为只要改变长度就能解决的。（对于野兔爱好者，这可真是乐事一桩，有些小动物还在野地里跳得欢呢。）
• 提高团队绩效。 团队已经有一种在sprint进展中丢失关注的倾向。为了阻止这种状况的发生，他们在第二周之后简单地开了另一个sprint计划会议，为了能找出目前的状态（尽管我们一直更新燃尽图），以及通过重新分配任务来纠正他们的计划。这不是一个理想的情形。
• 从产品管理团队（用户代理）得到更早的反馈，从而从产品真正的用户那里得到反馈。通常在sprints结束的时候，用户故事被用来评审。在三到四周时间里开发的大量的用户故事增加了管理的工作难度，他们会很难确定项目质量，以及为下一sprint计划bug fixing或者变更。
• 让公司做更频繁的发布。公司的正式计划是季度发布，但是我们希望有更加频繁的发布可能。
• 消除计划难度。做每月sprints，产品负责人需要提前四周进行计划，由于时常变化的商业优先级，有的时候有点困难，同时，这对于开发团队来说，也有困难——相当多的故事我们需要考虑，这样计划需要很长时间，同时经历也被耗费。
• 更快地学习。我们需要等待至少四周时间才能看到任何我们开发过程中的变化所产生的效果。而且我们经常希望在单一的sprint里做了那么多的改变以至于我们不可能专注于所有的事情。我们在sprint回顾中所确定的问题在后来的一些过程中又一而再再而三地出现。
还远远没有完成
截至目前为止，团队已经完成了三个双周sprints。在这个时间里，完成以下任务（或者抓住以下野兔）：
• 提高团队表现。团队开始更加专注，这点他们自己也非常喜欢。现在他们还能够记住大部分sprint的用户故事，这让他们彼此之间沟通他们的状态更加轻松容易。但是他们中的有些人说，如果用户故事的难度提高或者内部复杂性增加，他们就不能够这么好的完成sprints 。
• 及早得到反馈。这点已经得到产品经理的确认：他们能够得到客户的更早反馈，得到开发人员的估计，以及更早地更新计划，继而缩小整个反馈环节。
• 降低计划难度。这一点所有受影响的人都可以看到。对于Alexey来说 (一们ScrumMaster)，这样的计划是最难的：要考虑太多的故事，要大力好太漫长的会议。现在计划就像每日站会一样轻松简单了。
• 更快地学习。过去的六周里，我们已经开了三次回顾会议（如果我们进行每月sprint话，我们最多只能开两次），这个非常富有成效，并且易于操作。 参加的人员要列出所有的障碍也不匆忙，因为我们知道两周之后我们可以再来回顾一次。
截止目前为止，下面的目标还没有达到：
• 让公司做更多的发布。这依旧是下一个或两个季度的目标。.尽管上个月的质量有所提高，但依旧还没有不能够在还没有做一两个特殊sprints漏洞修复的情况下就可以直接发布软件。
所有这些积极的改变是因为我们切换成两周sprint带来的吗？不。缩短sprint 长度本身，产生了积极效果，但是倘若没有其他必须的改变，这些积极效果也是达不到了，比如增强团队的积极性和职业道德，提高和增加产品管理和开发人员之间的沟通 （在介绍产品故事方面）以及提高内部产品质量。
我们应该在一开始就做两周sprints 吗？我们不这么认为。我们还是认为要不是有这些良好的先决条件（信任，用户故事，良好质量，等等），我们就已经失败了。慢慢地开始，解决这些先决条件因素，我们慢慢的能够发布越来越快，然后很自然地调整sprint长度。毕竟，是要先学会走路，再学着跑。
原文地址：http://www.scrumalliance.org/articles/10-rethinking-sprint-length
