前文说到，团队和团队领导可以通过剩余时间燃尽图来了解团队的真实进度。确实是这样的，通过团队录入实际的剩余工时，确实可以得到比较准确的进度信息。这个已经非常好了，怎么还有一个故事点燃尽图？都是燃尽图，有什么不一样的吗？
我们来看看下面的剩余工时燃尽图表示的进度情况：
团队每天都努力的完成任务，使得红色的燃尽线尽量靠近灰色的理想燃尽线。一个迭代下来延后、预警、正常、提前、延后、正常，起伏跌宕，估计团队领导的心情也是起起伏伏。少不了找团队去了解具体的情况，看有没有问题，是不是需要解决什么问题。
但是，要问一句了。这个进度是我们想要的进度吗？
“什么，你花了这么多篇幅就是要告诉我们前面讲得都是没用的？！”
“咳咳，注意审题。我问的是这是我们想要的进度吗？”
“什么！？，这不是你讲得吗？说又可以得到客观的进度信息，还可以得到实时的进度数据，这不就是我们要的进度嘛！”
“好吧，我们来说说我们想要什么。”
“什么，我们要什么还不清楚吗，这还用问！不就是要得到任务的进度情况吗？ 难道不是吗？”
“。。。。。。”
“不说话，难道不是？～～～，我们要的不是任务的进度？，嗯？．．．．．．那你说，我们要什么呢？”
“当我们对客户说完成的时候，是说我们的某个任务完成了呢，还是说客户要的某个价值实现了？”
“嗯．．．，这家伙又开始说价值了”，“我们对客户说完成当然说的是价值实现了，我学过敏捷！可是我们现在没有对客户说完成了呀，是让团队告诉我完成了多少。就说任务的完成情况不是也行吗？”
“那你是希望团队交付给你一个真正完成的价值呢，还是希望团队交付给你没有实现价值的任务呢？”
“嗯，那还是希望团队给我交付的是价值，我给客户的时候也是交付的价值。”
“所以，我们我们衡量进度的时候，应该拿什么衡量呢？”
“难道要拿交付的价值来衡量，怎么衡量呢？ ～～好像着了他的道了～～，如果要衡量的话，就要拿交付的价值来衡量，敏捷里面学到的故事点就是来描述价值多少的，难道，难道要拿完成的故事点数来衡量？？？”，“哦～，好像可以拿故事点数来衡量，不对，别开玩笑了！！！拿故事点衡量，笑话笑话，看看他们故事点的燃尽图，能表示进度吗？”
“这进度天天延迟，最后一天正常了，这能表示出进度来吗？？？”
“请看第１～２天之间，燃尽线下降的一点，它表示什么呢？”
“这有什么，不就是代表了完成了一个Story吗？”
“那么，完成一个Story表明什么完成了呢？”
“那还不简单，不就是你推动的DOD标准满足了以后才能关Story嘛！”
“那达到DOD标准意味着什么呢？”
“嗯？那不就是开发、测试、自动化相关的工作都做完了呀！”
“那客户可以使用这个功能了吗？”
“那当然，都达到DOD标准了，客户当然可以用了。”
“那站在客户的角度，我们是不是完成了一点价值交付呢？”
“嗯？怎么一直问来问去的？难道我哪里理解的不对？”，“是完成了呀。”
“那我们的进度不是不前进了一点？”
“～～～是，可以～这么～理解～～～”
“那么故事点燃尽图是不是可以理解为，按照客户可以使用的标准，我们的客观进度情况的总览图呢？”
“～～～原来是这么回事～～～”，“哦，我理解了，只要有燃尽线下降，就说明我们按照客户可以用的标准完成了一些任务，这些任务正好是一个用户故事。”
“对喽，一个用户故事就是一个价值呈现，完成一个用户故事就是完成了一些故事点的价值交付”，“再升华一下，敏捷原则里面提到可工作的软件是衡量进度的首要标准，一个完成的用户故事是不是一个可以工作的软件呢？”
“原来如此。不过上面那个故事点的燃尽图岂不是体现不出进度了吗？”
“也不尽然，它说明我们在迭代的８天中间一直没有能够真正完成一个价值交付。而这正是敏捷团队需要努力锻炼获取的能力。现在看看这两个进度播报，你想要哪一个呢？”
“～～废话，那还用问，肯定是下面这个了～～”，“我当然想要下面这个了”，“～～敏捷团队可以在迭代中间就不断的交付价值，而故事点燃尽图可以看到这些交付的价值，从而可以真正衡量进度，也就是价值真正交付了，没有搽屁股的工作要做了～～”，“可是我们的团队肯定现在还没有这样的能力，不然不会一直是红色的。怎么能获取这样的能力呢？要不然故事点燃尽图也不好用呀。”
“在迭代中就可以交付价值，需要团队熟练掌握拆故事的能力，可以看看下面熟练团队的故事点燃尽图。但具体怎么做，且听我下回分解”。。。。。。
“什么，这就走了，不行！你给我回来～～～～”
“唉～，遇到这么一个直脾气的同学，扑哧哧哧～哧哧～哧～～～～”
闭关疗伤中．．．．．．
注：故事点燃尽图，体现了站在客户角度，使用可用软件的概念，来衡量真正进度的技术。在掌握了使用故事点燃尽图来播报进度的能力后，团队应对变化、快速交付价值的能力也会得到极大的提高。但是在团队暂时没有获得这样的能力之前，可以临时使用剩余时间燃尽图代替。
且听我下回分解 之 如何拆分用户故事