燃尽图功能及要素
燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。这个词常常用于敏捷编程。
燃尽图用来观察项目过程中完成的实际工作量与剩余时间的关系。燃尽图的纵轴可以是整个项目的剩余的任务，也可以是个人剩余的全部任务。
使用燃尽图的意义
“燃尽图”展示了一种新的管理工作报告，他向管理者与利益相关展示了目前产品BackLog完成情况与整体进度，管理层与利益相关者可以很容易地通过燃尽图了解实时的进度以及细节，管理层更能够实时把握产品的进度并做出正确的决策，并且预计风险，同时随时调整计划。
传统的项目报告一般是固定，系统的，向管理者展示了项目的进展，完成百分比，以及遇到的问题，需要解决与补救的方法，而实际上在开发过程当中，又会有不断的需求加进来，这种传统的项目报告无法应对这种需求，导致往往项目执行者将项目的失败都归咎于需求的增加与变化，并且责备管理层不能做出正确决策
如何去向应对变化以及让管理层与利益相关者做出相对比较正确的决策，就需要项目执行者向管理层与利益相关者展示项目细节，其必须具备可视性，可信性，可估量，充分展示项目执行的细节，而燃尽图可以解决这样的问题
什么样的燃尽图可以达到效果
在文章开始，我们已经解释了燃尽图，并给出表示方法，可惜我们不是寻找一个包装得很好看的图表，而是寻找一种方法去解决项目当中的问题，燃尽图可以帮我们解决问题，它是一种方法，必须达到某种效果，如果甘特图也可以帮到我们，我们同样也会利用。因此我们在乎的它产生的效益与成果。
那么我们应该先想好燃尽图
应该具有什么样的效果？
或者说如何解决传统
项目当中无法解决的问题？
前面讲到传统项目的报告往往比较迟纯，不能够及时调整，并且一旦需求一变，项目失败的机率就会增加，往往管理者决策的时候已经无法补救，另外管理者很难看清他投资的效果。因此我们可以要求燃尽图必须具备以下几种效果：
1)：
具备可视性，直观展示项目进度与BackLog完成情况
2)：
具备风险预估，提醒管理层与利益相关者目前完成情况，瓶颈出在哪里？
3)：
具备可估量，直观显示当前项目需要的时间
燃尽图实例分析
本项目采用燃尽图（Sprint Burn-down chart）对迭代进展进行监控及趋势分析，各燃尽图根据Sprint backlog每日的更新数据由EXCEL自动绘制。
燃尽图横坐标：工期。
燃尽图纵坐标：sprint 内工作任务的总承诺工时。
计划曲线：假定成员工作生产率恒定情况下的进展曲线。
实际曲线：实际进展曲线。
Spring_1分析：
1. 团队成员开始第一个Sprint，对于工作任务的分解掌握的不纯熟，对自身的工作生产效率不清楚。所以导致7月13日工作任务的进一步细化分解，导致实际曲线要高于计划曲线。
2. 虽然，7月12日到7月18日，实际曲线高于计划曲线，但是实际曲线的趋势与计划曲线相吻合，说明团队成员的生产速率是恒定的。
3. 7月19日，实际曲线回落，开发组将迭代版本提交给测试进行迭代系统测试导致。
4. 最后工时仍然存在，表征成员工时预估存在问题。
5. 本次sprint回顾会议上，团队成员认为“开发与测试结合紧密，版本能够及时发布与测试”
Spring_2分析：
1. 7月25日到7月29日，趋势基本正常。
2. 7月30日，实际曲线上扬，经分析发现仍然存在任务分解的颗粒度不够问题，成员发现任务越做需要的工时越多。深层次的原因是任务在一开始分解时，由于需求，设计等原因，导致任务工时预估与实际存在较大偏差。
3. 本次sprint回顾会议上，团队成员认为“团队工作时间把握更准确”，但是“任务颗粒度需要适当，目标要明确，不存在跨迭代。任务分解需要改进”
Spring_3分析：
1. 整体趋势正常，但是真实的原因是外界涌入了大量新的任务，影响了时间盒，为了保证版本交付，原来规划的一些任务进行了搁置。
2. 本次sprint回顾会议上，团队成员认为“项目内部临时增加的任务较多”，需要“sprint内的任务bug需要修改；sprint外的BUG工时较多时，需要评估，考虑建立新任务”；“项目外临时任务经常加入SPRINT”。
Spring_4分析：
1.8月24日，由于PB里面已领取的用户故事条目发生需求变更，导致预估工时大幅提升。
2. 本次sprint回顾会议上，团队成员认为“需求描述需要明确到位，需求上的细节变更要沟通及时，”“PB本身不够清晰，需要在sprint之前进行细节上的细化，团队每一个成员都会参与需求的分析和细化，时间与sprint并行；团队成员对需求的明确结果应一致”
几幅燃尽图只是实际敏捷开发项目中节选的几个SPRINT燃尽图，关于后续的敏捷实践记录