一轮迭代完成的故事点就是项目的速率。为这个项目做计划时，我们可以用已知的速率，我们也可以自己假想一个速率。速率是一个有用的管理工具，所以在每轮迭代结束和迭代中监控团队的速率是很重要的。
测量速率
多数故事很容易清点：团队在迭代中完成了这些故事，所以他们的点数全部计算在内。假如一个团队某个迭代中的速率是23。如果发布计划假定的速率和23差别很大，就有必要重新审视项目计划。但是，注意不要过早地调整发布计划。不仅仅因为是最初的速率往往不准确，而且速率在初期的迭代中也很不稳定。可能需要两三个迭代之后，才能获得一个长期的，比较稳定的速率。
但是不能将部分完成的故事也计算在速率中。
注意：不用实际小时作为速率。
计算速率是用迭代开始前分配的故事点数。一旦迭代完成，就不要改变迭代中团队获得的任何故事点数。举个例子来说，假如一个故事估算是4个故事点，但其实更大。后来团队发现他们应该估7个故事点。在计算速率时，这个故事应该算4个点，而不是7个点。
通常情况下，应鼓励团队在为下轮迭代计划速率时，不要超过上轮迭代的速率。然而，如果团队确实认为有个故事被严重低估，在下轮迭代中他们能做更多，就应该让他们计划一个稍微高一些的速率。
虽然团队不能返回修改一个已经完成故事的点数，但他们应该用这类信息调整后续故事的估算值。
计划速率和实际速率
监测实际速率与计划速率的偏差，或者说，是否需要采取什么措施保证合理的速率，这是很重要的。一个比较好的方法是为每轮迭代画出计划速率和实际速率。如图11.1所示，计划速率一开始低，但是之后开始增长并在第三轮迭代趋于稳定。
图中画的第三轮迭代的实际速率超过了第一轮的计划速率。然而，第二轮和第三轮迭代的实际增长不如计划，所以实际速率比计划速率稍微低点。
图11.1中的团队如果按照第一轮迭代得出结论并告诉客户他们超过了计划速率可以将交付日期提前，那他们就错了。那看看3轮迭代后怎样？团队是不是可以说他们应降低客户对发布计划的期望？要回答这个问题，团队不仅需要图11.1中的速率图，还有图11.2中的累计故事点图。
累计故事点图表明了在每轮迭代结束时总共完成的故事点数。由此，我们可以在图11.2中看出尽管第2轮迭代的进展比计划缓慢得多，第2轮迭代结束后，团队实际完成的点数还是比计划的多。但是，在第3轮迭代结束后，团队在第一轮迭代建立起来的优势被第2轮和第3轮迭代的较慢进度蚕食殆尽。
在第3轮迭代结束后，团队很有可能不能按照计划完成那么多的功能。如果客户不能在每天与团队的沟通中意识到这点，团队应当及时让客户了解目前的状况。
迭代燃尽图
另外一个监控进展的好方法就是迭代燃尽图（Burndown Chart）。迭代燃尽图展示了以故事点表示的再每轮迭代末剩余的工作量。图11.3就是一个例子。
燃尽图有一个有趣的特征，既可以从中了解到用已完成的故事点表示的进度，也可以从中了解到对发布剩余计划故事点数的改变。
从图11.3中可以看到，团队在第一轮迭代实际取得了负进度。我们不能从燃尽图中得到团队前进的速度。图11.3中的团队可能完成了90个故事点，然而可能增加了95个故事点。想知道团队完成了多少故事点，应该看速率图或累计故事点图。
即使燃尽图不能表示团队的开发进度，但它还是很有用，因为它能更好地展现项目的整体进展。敏捷软件开发的一个优点就是项目开始时不需要为项目需求写冗长完整的说明。敏捷团队都承认客户不可能预先知道所有事情的事实。因此，敏捷团队会要求客户提供尽可能多的信息，并允许客户在项目过程中修改或精炼他们的想法，大家在一起学习如何构建软件。也就是说不断会有新故事涌现，也会有旧的故事因为变得没有价值而被取消，故事的规模和重要性也会不断进行调整。
迭代中的燃尽图
燃尽图不仅可以用于在迭代结束时跟踪进展，它还是迭代期间一种很好的团队自管理工具。在迭代中，每日燃尽图可以展现在迭代内剩余的估算小时。
NOTE：是剩余小时，而不是花费的小时
注：本文来自于网友对《用户故事与敏捷方法》(作者：Mike Cohn)一书的书摘
