看到有的团队在Grooming会议、迭代计划会议上对Story估算了点数以后，到了后期发现点数当时估算的不准确，于是就来问了：之前这个story是5个点，结果做到现在了，我们发现它根本不是5个点的工作，应该是13个点，我们是不是要把这个Story的点数更新一下？
嗯，这个请求看起来合情合理。同意吗？还是不同意？到底是修改呢还是不修改？
这其实就回到了敏捷的出发点，为什么敏捷要不断得做计划（迭代计划会议），为什么要经常检视计划调整计划（每日站会），根本的原因在于敏捷承认，基于软件开发的易变性、不确定性、复杂性、模糊性，任何事先的计划都是不准确的。所以需要不断得渐进明细去更新计划，使得之后的计划能够越来越接近准确。
所以当团队在启动迭代时对于迭代内的Story的估算（故事点）代表了团队当时基于对所有信息的了解而形成的对于需求的理解程度。事后来看，它代表了团队在当时的计划能力或水平。我们希望团队在信息不完整的情况下能够给出一个比较靠谱的计划，这实际上是需要团队具备的计划估算能力。
那么怎么衡量团队计划能力的高低，其实就拿团队在迭代完成的故事点数与承诺的故事点数的比值就可以得到团队做计划的靠谱程度。希望这个比例在90%-110%之间，说明团队能够比较好地应对这样的不确定性。
比如还拿一开始的例子来说：一个初始估计是5个点的故事，实际做的时候发现相当于13个点故事的工作量，有两种情况。一种是这个故事在当前迭代还是完成了，那么团队也知道了这样故事的复杂度，下次碰到了类似的故事就自然会估的更准确些。但是这个迭代只完成了团队一开始认为的5个点的故事。另一种情况是团队在当前迭代没有做完，那么这个迭代没有能够创造这5个点的价值，知道在后面的迭代中完成这个故事，才能在那个迭代挣到这5个点。而经过这么辛苦的努力才挣到5个点，那么下一次，团队在估算时也会更努力的估算准一些。
而反过来，如果团队随时调整故事的点数，虽然是数据准确的，但是不能反映出团队在做计划时的估算能力。而且每次迭代完成时，所有的更新后点数都会是准确的。这样，团队就失去的改进的动力，估算不准后面调呗，这样的计划会议就会失去意义，不能变得越来越准，不能起到有效指导团队工作的目的。团队的估算能力也不能快速提高。
而JIRA背后的产品经理，深知这个道理。于是在形成迭代报告和Velocity报告的时候，Story的点数总是迭代开始时第一次估算的点数，后面再怎么修改点数也是不会反映到这两个报告里去的。
大家可以试验下，再好好想想是不是这个道理。
