在敏捷开发中最重要的原则之一就是使用燃尽图报表。基本上有两种类型的燃尽图报表；基于剩余时间的燃尽图，和基于剩余点数的燃尽图。

基于剩余时间的燃尽图是一种比较流行的方式，它描绘了Sprint日常工作进度以及预计剩余工作时间。

基于剩余时间的燃尽图具有以下优点：

• 易于实践和推广；它真实反映了每个开发人员估计的剩余时间。对于一个有经验的团队成员，完成某个任务可能需要1天时间。但对于一个新手，同样的任务可能需要3-4天。
• 这种做法鼓励每个开发人员每天对各自负责的任务进行剩余时间的记录。反过来又促进了每日“立”会变得更富有成效，因为每个任务每天都经过评审，或新更新了实际需要的剩余时间。
• 它有助于创建一个自我驱动的团队，为项目带来可持续的成功。

基于剩余时间的燃尽图也带来以下缺点：

1. 每个团队成员每天都要被强调去记录每个任务的剩余时间。这种做法在某些时候会变得难以遵循，因为它需要改变公司或者团队的文化和工作纪律。
2. 剩余时间的输入及编辑，有时可能会为团队成员带来额外的工作量。
3. 团队成员对完成项目或Sprint的剩余工作时间估计不够准确。

相对剩余时间的燃尽图，有另一种基于剩余点数的燃尽图。这个报表可以基于任务的点数，而不是任务的剩余时间，来跟踪工作进度。

Story和任务的点数用来表示每个任务和Story的功能价值，或者技术等级。点数常使用一个相对值，代表了要完成任务所需的工作量，也可以代表Story或任务的难度水平。

下图是一个基于Story/任务点数的燃尽图范例

点数燃尽图显示了开始执行时有一个初始估计的总点数，然后随着任务不断被完成和关闭，剩余点数逐步下降的过程。

点数燃尽图具有以下优点：

1. 它只需要由产品负责人，Scrum Master或团队用点数来为任务进行估计，而不是具体的时间值。基于点数的估计有时比基于时间的估计容易得多。
2. 只要任务在规定的时间内被完成并关闭，就会生成一个足够体面的燃尽图，来反映Sprint的进度。
3. 它鼓励了所有团队成员为完成预定的任务而感到骄傲，并获得个人价值的认可，因为完成的点数代表了他们为可执行软件的贡献。

点数燃尽图有以下缺点：

1. 它不能准确预测当前Sprint中承诺任务的具体完成日期
2. 它鼓励了所有团队成员平等做出贡献，但是没有考虑到初级工程师需要更多的努力才能完成相同的点数。
3. 我们比较容易建立这样一个团队，即让团队成员根据自我估计，并对工作量进行承诺。然而使用点数对任务进行估计，任务分配时将出现“平均化或偏重挑选”。

剩余时间燃尽图描绘了团队成员名下所有任务的每日进度。点数燃尽图则基于任务完成状态，来描绘Sprint进度。由于某些任务可能需要几天才能完成，点数燃尽图未必能反映团队成员名下所有任务的每日进度。

总的来说，基于剩余时间的燃尽图，能有助于建设一个长期的自我驱动团队；它让团队成员自己来预估工作量并做出承诺。基于点数的燃尽图，能有助于建设一个高效的团队，让所有团队成员都能平等的做出贡献。