在早期的Scrum培訓中，燃盡圖的典型畫法如下：
1，在Sprintd的第一天，識別所有任務的工作量，常常使用理想工作人天作為單位，縮寫是IMD，全文是ideal man day，這樣得到燃盡圖的第1個點
2，以后每天跟蹤各個任務未完成的工作量，早期的工具不多，常用Excel來跟蹤，并利用Excel來繪制燃盡圖。跟蹤部分形狀如下：

利用Excel繪制得到的燃盡圖如下：

為方便討論，將此畫法在本文稱之為A畫法。
假設一個團隊有7個人，選擇2周10個工作日作為一個迭代周期，那么一個迭代可以提供的總工作量是 70個人日，大概約可以處理50 IMD，如果把任務一一對應到用戶故事，那么平均一個任務的工作量約是3 IMD，那么這個迭代有約16個任務。

在后來的發展中，出現了多種燃盡圖畫法，常見的有：
B畫法，以工時為單位，即是燃燒工時，burn hours
由于IMD的最小顆粒度一般是0.5IMD，對應4工時，IMD不能支持更細顆粒度的工時，而工時作為單位，顆粒度可以到最小0.5工時，因此工時作為單位就能表現更小顆粒度的任務。
同樣假設一個團隊有7個人，選擇2周10個工作日作為一個迭代周期，那么一個迭代可以提供的總工作量是 70個人日，560個工時，如果識別用戶故事下的不同任務，平均任務工作量是8工時的話，那么有70個任務；如果平均任務工作流是4工時的話，那么有140個任務。
假設每個任務的識別和估算需要2分鐘，140個任務的識別和估算就是需要280分鐘。此畫法的好處是便于跟蹤，完成的任務剩余工作量為0，這很清晰，每天的進展反映清晰。
C畫法，仍然以工時為單位，把任務估算與故事點掛鉤
由于這樣的識別非常耗時，一個折衷的做法是根據故事的故事點數直接估算任務工作量，比如故事點在撲克游戲中得到是3，根據歷史數據，每個故事點約需要1.8工時，那么這個故事對應的任務估算工作量就是5.4工時。C畫法與A畫法存在相同的問題，任務一般不能在一天之內做完，因此需要對開始了但沒有完成的任務進行剩余工作量的估算，這樣的估算一般難以準確。
D畫法，以故事點為單位，即是燃燒故事點，burn story points
燃燒故事點的好處是直接以工作對象為度量，與交付直接相關，但其弊端是當故事沒有完成時，故事點是不燃燒的，故事點為單位的燃盡圖在前期往往下降緩慢，頭幾天甚至多數情況下是平的，因而利用故事點燃盡圖不能直觀的預測能否按期完成所有故事。

隨著看板在敏捷迭代當中的使用，比如ScrumBan、Kanban，用戶故事的狀態不再只有”to do”,”in progress”,”done”，常見的狀態有開發，測試，狀態內又能分成 doing，done，結合經典的掙值分析，迭代燃盡圖有了一個新的畫法，在本文稱為E畫法：
E畫法，以故事點為單位，根據狀態的完成度比例來得到為完成的故事點
1，采用故事點作為單位，給不同狀態設置不同的完成度百分比，比如 開發 doing 對應 15%， 開發 done 對應 40%， 測試ing 70%， 測試 done 90%, done 100%
2，當某個故事點為5的故事進入到開發done時，其剩余故事點計為3（計算式：5*（100%-40%））

這個方法的原理是狀態代表了故事開發進度的掙值，對比D畫法，能夠在過程中顯示進展，無需等待最后完成的時候，對比C畫法，狀態代表的掙值比每天都人工估算剩余工作量更加客觀；對比B畫法，識別和估算的時間可以大大節省，在計劃會議上不再需要時間來識別和估算任務。

對于B畫法，雖然形式上是敏捷開發的形式，但在內容上卻是與傳統的MPP日跟蹤在顆粒度上是一致，讓團隊成員識別4小時顆粒度左右的任務，對比項目經理識別4小時顆粒度左右的任務，所費時間可能更久，在原來Excel的情況下，往往是專人跟蹤剩余工時，對比項目經理跟蹤MPP，所費工作量相當，在新的工具下，每個人每天跟蹤自己任務的剩余工作量，對比Project團隊版自行跟蹤自己任務，也是非常相似的。

總結

以上是生活随笔為你收集整理的迭代燃尽图画法小议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。