我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说，有几个方法可以选择。有些团队把每个用户故事拆分成以天为单位的任务。但是．．．
我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说，有几个方法可以选择。有些团队把每个用户故事拆分成刚好一天能够完成的任务。但是我见到不少团队在尝试过这么做以后，发现过程中遇到很多麻烦，因为有些任务需要不到一天，而有很多需要两天甚至以上，所以很难将所有任务都准确地拆分成正好一天能够完成。
有的团队把用户故事拆分成任务以后，花费大量的时间来计算每个任务所占的故事点数。而这个会在计划会议上完成，因此整个会议要持续4到6个小时。在下文中，我们把这种方法叫做“故事点数分配法”。
第三种方法是我最喜欢的一种，我觉得它是最有用的，因为这种方法不需要花费很多时间，这和Scrum中帮助团队避免花费太多时间在获得准确性的其他方面是一致的，例如，在Scrum中使用斐波那契数列或者2次方数列来进行用户故事的估计。
只要有机会，我都会推荐下面这种方法。这种方法的基本技巧就在于，持续地更新每个用户故事的估计所需剩余时间(ETC)。一般来说你可以在每日站会之后更新数据，如果你已经能够掌握时间盒的运用的话，你甚至可以在每日站会当中来更新。总而言之，这种方法的最基本思想就是让团队每天估计并且更新完成某个用户故事所需要的故事点数。
让我们来看看这个例子。假设我们的Sprint长度是两个星期。在计划会议之后，团队承诺完成A到G一共7个用户故事，放在下面的表格里面（图1）。
图1
图2
在完成了星期一下午的工作以后，团队在星期二的早上聚集到一起举行每日站会，然后估计所有在进行中的用户故事所需要的剩余时间。从图2中可以看出，用户故事A和B正在进行中，于是团队根据当前的进展重新估计了这两个用户故事剩余的故事点数。做出估计的依据应该是整个用户故事所剩余的工作量，而不是被拆分的任务。下面是团队重新估计后得出的燃尽图（图3）。
图3
团队应该每天重新估计每个进行中的用户故事的剩余工作量。图4展示了从开始到完成的过程，图5则是Sprint结束时的燃尽图。
图4
图5
我经常听到其中一个的争论是“但是ETC并不是百分之百准确的”。这是肯定的，没有任何的估计是百分之百准确的。但是，每天重新估计进行中的用户故事的剩余工作量比把故事点从Sprint开始分配到各个任务中，然后每天把剩余的故事点数加起来更加能够让你了解实际剩余的工作量。这是为什么呢？
我们可以用锥型不确定性理论来解释。在项目管理中，锥型不确定性描述了项目过程中不确定性数量了变化过程。在项目刚开始的时候，相对地我们对项目的了解较少，因此估计也会包含比较大的不确定性。随着我们完成了越来越多的开发工作和研究工作，我们对项目的了解也越来越多，不确定因素也会越来越少。(http://en.wikipedia.org/wiki/Cone_of_Uncertainty)
正如你所想到的那样，锥型不确定性理论对传统的项目管理模型有很强的依赖。尽管如此，它的原理同时也适用于敏捷的项目管理。
还记得“故事点数分配法”（把每个用户故事的点数分配的各个任务当中）吗？我们可以说我们已经有一个不错的误差了，姑且说是+/-25%(1.25/0.75)吧。当然这种方法不会让我们得到百分之百的准确度。当项目进行的时候，为了能够更好地计算剩余的工作量，团队会标记已经完成的任务，然后把在进行中的任务所占的故事点数相加。这么做的问题是，尽管我们现在能够掌握比我们第一次估计的时候更多的信息，但是由于我们没有对用户故事进行重新估计，于是我们的准确度就会卡在+/-25%这个槛上。
如果我们不在一开始就把故事点数分配到各个任务上会发生什么事呢？自然我们就不会把所有剩余的任务所占的故事点数加起来来获得剩余的工作量。我们只能够重新估计每个进行中的故事的剩余工作量。这样我们就可以保证我们重新估计的时候不会还带着+/-25%的误差，而且可以越来越接近锥型的右侧，也就是误差为0的地方，因为我们每次重新估计的时候就会比上一次更加了解项目掌握的信息也会更多。这样做会比单纯维护在计划会议上作出的估计要准确得多。
我推荐各个团队在下一个Sprint中尝试这种方法。如果使用得当的话，你将会很快地留意到持续估计剩余工作量的好处。
原文地址：http://www.scrumalliance.org/articles/356-measuring-sprint-progress
