敏捷团队的速率是由团队成员本身的能力所决定的，一般会在一段时间之后达到稳定值。稳定之后的速率可以用来做项目计划和发布计划。
然而，从实际经验来看，团队的速率不会是永远一沉不变的。首先，团队速率可能会在一个范围内浮动。比如，在一段时间内，团队的最高速率可能是42（故事点），最低速率是22（故事点），平均速率是34（故事点）。浮动的原因有很多，Sprint3和Sprint4中有较大浮动的原因可能是有成员休假，也可能是遇到了服务器故障等意外事故。Sprint2和Sprint6速率较高的原因可能是团队工作在较熟悉的代码上，也可能是团队的心情曲线较高。
.png)
无论如何，团队的速率是会浮动的，而且浮动的速率仍然能作为计划的依据。我们可以以最大速率做一个最乐观的计划，以最小速率做最悲观的计划，平均速率做一个最可能的计划。
如果需要完成的东西是固定的，那假设产品Backlog的大小是200个故事点。如果按照平均速率来算，我们需要200 / 34 ~ 6个Sprint完成。如果按照最大速率来算，则需要200 / 42 ~ 5个Sprint完成。同样，最小速率需要200 / 22 ~ 9个Sprint完成。根据这个数据，可以做出这样的推算：项目最快还需要5个Sprint完成，普通情况需要6个Sprint，最差情况需要9个Sprint。
如果项目的时间是固定的，我们可以推算出在项目结束的时候，能完成多少故事点的工作。假设还剩3个Sprint，那团队最快可以完成 42 * 3 = 126个故事点，普通情况完成 34 * 3 = 102个故事点，最差情况完成22 * 3 = 66个故事点。
团队速率的浮动是正常的，不能可能让团队永远稳定在最大值上。但是，从更长远的角度看，团队的速率可能会有增加会减少的趋势。从实践经验来看，影响团队长期速率的因素包括：
- 团队的稳定性。一个长期稳定的团队在经历一定的磨合之后会通过不断进行适应和调整而达到高效，速率也会慢慢增加。然而，团队的成长是有一个长期过程的。如果打破团队，那也可能会经历速率的快速滑坡。
- 代码的质量（技术债务）。如果团队在一开始只注重开发的速度而不注重代码的质量，从长远来看速率会降低。相反，如果团队工作在遗留代码上，在一开始花了很多时间清理技术债务，那可能在开始的时候速率比较低，但随着技术债务的清除，速率会慢慢增长。
- 完成的定义（DoD）。一个好的团队会不断扩大完成的定义。可能一开始的Sprint结束只包含开发和功能测试，并不能交付真正可工作的软件。但是随着团队的成长，DoD可能会慢慢延伸，逐渐包含压力测试，稳定性测试，安全性测试，客户验收，布署等所有可工作软件需要的东西。所以，可能看似团队的速率减慢，其实是团队省下了项目发布后期的很多工作，为整个项目节省了时间。
- 成员的能力培养。团队成员可能为了拓展团队成员的能力，在某一段时间挑选自己不熟悉的任务来做。这从短期来看可能会减慢速率，但是从长期来看可以减少团队的瓶颈，增加团队的合作性，从而提升长期速率。
无论是什么原因，如果团队速率发生了变化，都是对团队成员和管理者的有效信息，需要在信息透明的情况下总结并且提高。整个组织也应该提供一个允许团队长期发展的氛围，承认团队速率的浮动是正常的，而且不要只顾短期速率而忽视了团队的长期发展。
