燃盡圖的功能與要素
燃盡圖可以說的上是最直觀的信息反射。它以圖形化的方式展現了剩余的工作量（y軸）與時間（x軸）的關系。讓我們感興趣的地方在於對燃盡圖的分析可以揭示很多問題，比如團隊的表現如何、如何進一步改進等等；它有助於把握團隊的進展情況。
燃盡圖功能大體可以幫助我們了解到團隊是如何制定的計划，在一個sprint中，團隊對計划是如何執行的，作為團隊，燃盡圖可以直觀的了解到大家的工作步調是否一致，通過燃盡圖還可以知道團隊哪些地方還有不足，還能進一步的提升。
燃盡圖主要分為其中情況：
- Fakey-Fakey：表面完美。軟件項目過於復雜以致於難以界定直觀的目標。大多數情況下，這種圖來自於充滿了命令與控制的環境，在這種環境下，開放的交流變得難以進行。
- Late-Learner：燃盡圖中會有一個頂峰。通常出現在溝通高效且正在學習Scrum的團隊中。
- Middle-Learner：要比late-learner更加成熟。團隊在Sprint的中期會探尋出大多數的任務與復雜性。
- Early-Learner：開始有一個頂峰，然后是平緩的衰退。團隊認識到早期探尋的重要性，然后高效工作以實現目標。
- Plateau：團隊在一開始取得了很大的進展，但卻在Sprint的后半部分喪失了方向。
- Never-Never：燃盡圖在Sprint的后期突然開始上揚並且不會再下降。需要盡快找到這些遲來的變化並進行自省。
- Scope-Increase：Sprint中的工作量突然增加。
燃盡圖的示例分析：
燃盡圖對項目進行直觀的分析。
燃盡圖橫坐標：工期。
燃盡圖縱坐標：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燃盡圖，關於后續的敏捷實踐記錄。
