燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。我们经常用到的燃尽图有两种类型，一是基于任务（task）的燃烧；另一种是基于故事点（Story point）的燃烧。燃尽图经常用在敏捷项目里，如果从迭代周期的维度看，还可以分成Sprint的燃尽图，用来记录Sprint的进度；也可以是release的燃尽图，用来记录整个scrum项目的进度。
上图是一个典型的sprint（iteration）燃尽图，如果迭代的Burndown Chart一直是上升状态，或当Sprint进行一段时间之后，Sprint Burndown Chart上当前点的Y值仍然与Sprint刚开始时相差无几，就说明这个Sprint中的任务过多，要拿掉一些story以保证这个迭代能顺利完成。如果Sprint Burndown Chart下降得很快，例如Sprint刚过半时Y值已经接近零了，则说明为这个Sprint分配的任务太少，还要多加一些任务进来。在迭代计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。总之，燃烧曲线是衡量团队进度的重要工具。
虽然大家对燃尽图都很熟悉，但我们在实际使用燃尽图的过程中，仍然有过如下三个疑问：
1. 在绘制燃尽图的时候，什么时候选择基于task度量，什么时候选择基于story point度量？
2. 谁来给出起始的故事点或者任务的estimation？
3. 在使用一些项目管理工具的时候，对于task的estimatoin，remaining time以及correction，这些不同的field代表什么意思？谁来给出这些值？何时修改这些值？
疑问1：在绘制燃尽图的时候，什么时候选择基于task度量，什么时候选择基于story point度量？
想要找到这个问题的答案，必须理解这两种燃尽图各自侧重的意义。虽然两者都是用来表示项目或者迭代进度，但story point更多体现的是业务价值的完成，比较宏观；而task关注的是具体任务的完成，较为微观。所以，基于story的燃尽，是在记录燃烧了多少业务价值，离最终交付给客户业务价值还有多远。我们知道衡量一个story是否完成还依赖于DOD（definition of Done)， 不同的团队对DOD有不同的定义，例如有的团队认为story必须经过showcase才算完成，那么会明显影响到基于story point的燃尽曲线。但task关注的是敏捷团队内部的开发情况，是基于person day的，只要这个开发或者测试的任务完成就算DONE。由此可见，story point的燃尽图体现的敏捷流程，关注业务价值的交付，可以暴露诸如测试滞后，协作子系统之间的依赖等问题；task（Person day）燃尽图体现的是开发和测试进度，关注团队内部的完成风险。
所以这两种方式有各自的侧重点，可以同时使用。但对于一个成熟度不是很高的团队来讲，使用task的burn down chart似乎更加现实；如果团队足够成熟，可以均匀地拆分user story，且每个story都比较小，整个组织也比较敏捷的话，就以用story burn down chart来取代task的burn down chart。也可以将两图合并, 同时从基于task working hours的burn down与基于story points的burn up两个视角关注项目进度。
疑问2： 谁来给出起始的故事点或者任务的起始estimation？
对于谁来给出起始故事点数来说，答案比较明显，那就是团队给出。但对于谁来给出具体任务的初始estimation，不同的团队有不同的做法，我们的实践也是团队给出。
在迭代开始的计划会议里，有很大一部分时间是团队一起拆分story，并且给出每个task的estimation。由于person hour和个体关系很大，不同的人对同一个任务预估的时间也不相同，也就说团队一起给出的这个estimation可能是取了一个平均值。
那么问题来了，这样做到底什么意义？平均值会不会不准呢？其实计划会议上所做的所有预估都是为了更好地在团队内达成对业务和工作量上的一致理解，团队不应该把关注点放在准确或不准确上。无论是故事点还是任务的PH，都应该建立在团队每个人对问题的一致理解之上。实际上，根据集体智慧的原理，多人一起预估会更加接近将要发生的实际值，也更能帮助团队做为整体对客户做出承诺。
疑问3：在使用一些项目管理工具的时候，对于task的estimation，remaining time以及correction，这些不同的field代表什么意思？谁来修改这些值？何时修改这些值？
首先要理解，敏捷里所有BVC（big visual chart），首要考虑的就是，这些图形或图表能够真实地反映项目与团队的实际情况，基于task的燃尽图也是如此。通常当进入实际开发，task的owner才会被确定，那么这个owner就可以根据自己实际的开发情况来调整时间。
不同的项目管理工具有不同的设置，例如IBM的RTC，task有三个与时间相关的field，其中estimation就是计划会议上大家一起给定的那个person hours，这个值不会再去修改；第二个是remaining time，这个值相当关键，它直接影响到燃尽图的实际曲线，owner应该频繁地对剩余时间进行修改，以便真实地反应任务的实际进度，一般至少是在下班前或者任务切换时修改；第三个值是correction，代表实际可能要花费的时间，越是接近任务完成的尾声，值越接近实际。这是一个非常令人迷惑的field，因为它十分容易让人联想到事后度量，甚至是绩效评估，而敏捷是反对这类度量的。实际上，correction本意是为了真实的得出remaining hours，在实际的开发过程中，随着时间的推进，owner越来越清楚可能的实际时间花费，这个值也许比计划会议上预计的estimation大，也许比estimation小，owner通过不断调整correction，将它与已经耗费的小时数做减法，从而得出剩余时间，使得燃尽图始终保持能够真实反映迭代进度的能力。此外，IBM RTC 自动生成的燃尽图也会有一条线是专门反映预估与实际的差距，可以用于帮助团队逐渐改进自己的计划会议。所以，correction也应该是随时可以修改的，并且修改的人是task owner。
举一个极端的例子来说明一下，假设一个迭代有6天，这个迭代里只有一个任务，estimation是24ph。进行到第三天的时候（已花费12小时），程序员突然意识这个任务要比原来想象中复杂，于是调整correction为30ph，remaining time变成18ph （correction - 已花费）。由下图一可知，更改correction是会影响planned以及Remaining这两条曲线。当然在实际的操作上，尤其是团队采用物理看板，由人工去维护燃尽图的时候，通常只需要简化成图二。当然，一个迭代是由多个task组成，那么整个燃尽图实际上是所有task不断更改correction与remaining time的效果叠加，籍此将Risk和Progress透明化，指导团队及时做出适应与调整。
一个敏捷团队在开始使用燃尽图的时候，容易陷入一个误区，就是将注意力放在生成漂亮的曲线上，而不是项目本身，这就失去了燃尽图的意义。所以作为管理层绝对不能过分依赖它作为监督和考核的依据，否则就会产生bed smell。