1. 发布燃尽图 Release Burndown Chart

分析每个迭代，实际线和理想线，能够预测发布的进度目标是否良好还是朝着延期的潜在可能

2. 发布燃起图 Release Burnup Chart

与发布燃尽图相反，燃起图展现的是在这次发布中，每个迭代已完成的用户故事点数。随着需求不断完成、价值不断累积，图形也不断上升

3. 燃尽图与燃起图混合 Burndown Chart & Burnup Chart

4. 发布耗散条形图 Release Burndown Bar charts

需要记住以下四个原则，耗散条形图是如何移动：

• 当开发团队**完成工作后，条形图顶部会降低**。
• 当**原本的工作量被重新估算时，根据估算值的增加或减少，条形图的顶部会上升或下降。**
• 当PO**添加新工作时，条形图底部会降低到X轴以下。**
• 当PO**删除工作时，条形图底部会向上升起，甚至可以升起到X轴以上。**

1. 迭代1：以预定义的速度开始发布的工作。条形图的高度表示计划发布的特性和故事点总估算值，为15sp（故事点）
2. 迭代2：当工作在完成时，我们发现条形图的顶部降低了2个sp。然而，在相同的时间内，一些工作被添加到迭代计划，此时被添加低于x轴的部分，被添加的在轴上表示为-3sp，因此条形图底部下降3sp。这可能是因为PO意识到在发布期间需要适应额外的工作量来达成业务价值
3. 迭代3：条形图顶部下降，说明工作继续被完成，但是下降的速度没有上一个迭代快。这表明在此迭代过程中团队的速度变慢了。实际速度的下降是完全可以接受的情况，可能是由于以下一个或多个可能的原因而自然发生的:
   • 一些故事估算可能被低估，并且随着团队更好地理解实际，增加了对待处理工作项的估算。
   • 一名或多名团队成员因病或休假而无法完成计划的工作量。在相同的迭代过程中，PO再次向待办事项列表中添加了一些工作，导致
   • 条形形图的底部进一步降低2sp。请注意，在这个时候，很有可能这个版本的待处理的工作量甚至可能超过迭代1开始时计划的总工作量（现在总的故事点数为：17sp）。
4. 迭代4：我们观察到一些重新评估提高了条形图的顶部，因此条形图顶部上升1sp。需注意，这并没有添加任何新功能，因为X轴下方保持持平，依然为-5sp。
5. 迭代5：在此迭代中，团队完成了更多的工作，条形图顶部的降低3sp。然而，PO也删除了一些工作（例如，从发布中降低优先级或认为不必要)，条形图底部底部上升3sp。这里需要注意！！图表并不需要告诉我们到底哪些工作被删除了（是最初计划的工作还是后来添加的工作，我们不需要知道）。但凡是删除功能，那么就要从条形图底部进行上升
6. 迭代6：在迭代6期间，条形图顶部再次降低4sp，意味着完成了更多的工作。我们还观察到条形图的底部被提升到X轴之上，这表示PO删除了更多的工作，合计删除了3sp。
7. 迭代7：目前的迭代中还剩下2sp，也没有更多工作被添加或删除，但是直到最后，工作仍然在完成中持续减少。
8. 正如上面的插图所示，发布耗散条形图是一种非常强大而简单的跟踪项目进度的方法，它展示了速度变化的概念，以及backlog中工作的动态加减或重新排序。

5. 迭代燃尽图 Iteration Burndown Chart

显示一个迭代中的每一天还剩余多少的用户故事点数没完成，一开始是这次迭代所要完成的用户故事总故事点数，所以燃尽图是点数越来越少，由高至低的图形