有幾種方法可以在Scrum中燒燬圖表。Scrum燒燬圖表：任務或故事？
有些人建議將未完成故事的故事點用作Scrum中的燒錄圖。
臨：只完成了故事降低圖表
魂鬥羅：圖表不會在一開始向下移動，然後迅速下降
其他建議使用的任務數左
專業版：圖表會向下移動，您可以看到它是否高於終點線
對比：你可以下來說10個任務（最困難的任務），並且還沒有完成一個故事。你失敗了，因爲只有完成的分析對你的產品所有者纔是有利的。
解決方案既包含點完成任務圖和未完成任務圖？
我們都這樣做，就好像我們沒有包括任務一樣，我們的行將以一種使得看起來沒有任何事情完成的方式高原化。
如果一個故事需要2天才能完成，那麼你的平均線數爲2天，並且無法判斷團隊是坐在他們的大拇指上，還是工作增加（因此工作時間跳過了） 。
當然，如果開發人員可以隨意選擇任務，任務線可能會直線下降，而不會對完成故事做出貢獻。
跟蹤剩餘任務的數量並不十分有用，因爲任務可能有不同的大小。
你不應該發現自己在一個情況下球隊完成10個任務，無積壓項目（實際上，這是可能的，如果你有10個開發人員）：每個開發人員不應該從另一個待定項（故事），直到拿起任務他完成了他所做的第一個故事所屬的積壓項目 - 如果任務形成另一個故事比從開始的故事開始的其餘任務更難。
在我看來，跟蹤任務是一種相當不理想的跟蹤方法。根據我的經驗，一個故事很少是其任務的總和 - 而且通常在實施一個故事的時候，我發現任務分解是不理想的。
而且，雖然我在估算故事的過程中發現了頭腦風暴任務的價值，但我更喜歡故事足夠小，因此我們不希望跟蹤。事實上，獲得完成任務的功勞非常具有誤導性，因爲即使完成了所有已確定任務的一半，仍然無法保證Sprint將提供任何價值。這就是利益相關者最終感興趣的內容：實際投入的價值有多少？
因此，追蹤故事並致力於進一步細分故事可以提供更準確的反饋，並降低無值交付的風險。
事實上，在處理小故事的時候，我並沒有在Sprint中看到太多價值 - 只是看着牆上的卡片從「做」到「進行中」到「完成」應該給你你需要的所有信息。然而，根據我的經驗，發佈版本可能會非常有價值。
+1追蹤時間是浪費。所有重要的事情都完成了。如果你還沒有燒燬一個故事，你沒有真正增加任何商業價值。 – DancesWithBamboo 2009-03-05 06:15:32
我們正在使用衝刺燃燒時間 - 團隊可以看到每天的進步。如果有平坦的部分，那麼它們確實發生了。
在發佈burndown我們使用故事點。發佈計劃更多的是關於他的功能完整性，時間在短跑級別上進行跟蹤。產品負責人對完成的故事感興趣。
任務數量無用。這個數字可以每天更改，特別是如果您給開發人員「自由」。他們可以在不改變總時間的情況下將任務分解爲較小的部分。這樣的統計是無用的。它是什麼意思？它會影響衝刺的目標嗎？
我們還追蹤剩餘時間（以小時爲單位）。每個故事都被分解成（理想情況下）小於16小時的任務。 – M4N 2009-01-03 19:31:24
我們通常需要跟蹤要求他們的客戶的小時數（估計值vs實際值與完成估計值）。這使我們可以做一些事情：
我們還跟蹤了我們自己的殺滅完成的故事，但作爲已經指出的那樣，這可能導致在那個用來告訴我們很少有用的信息（除了我們」其他的衝刺開始平臺效應平行不夠）。
我們使用任務是因爲它提供了更多的粒度。只記錄故事的完成情況（我們每兩週衝刺5-10次）只會顯示一兩天的變化，正如你所提到的那樣，衝刺開始時，動作不會變化太大。
我的團隊發現的另一個有用的東西是對每個「待辦事項」，「進行中」，「準備好質量檢查」和「已驗證」的每條線使用堆疊折線圖。通過這種方式，很容易看到創建備份的過程中的任何階段。
我用了大量的「剩餘時間」爲burndown。團隊總是發現，跟蹤時間跟蹤已經接近時間跟蹤系統，增加管理開銷，並且除非我們將人類轉換爲機器人，否則實際上並不準確。
我正在使用任務burndown（總任務，新任務，完成任務）。好多了。確實沒有看到已完成或已完成的任務的大小。但團隊每天都會見面，這就是你遇到問題的地方。另外，我指導團隊不要創造大任務（最多4到6小時）。另外，我添加了一個包含新任務和完成任務的其他圖表。團隊發現，通過任務燒燬更有意義，使用小時。
隊後明白打破在任務故事的價值，我想通過故事來試試燃盡。所以有最多5或8個故事點的小故事。從Jeff Sutherland博客，這是讓團隊獲得高績效的一大步。
另外，我想提一下，burndown只是一個「一目瞭然的進度表示」。對團隊和採購訂單來說，最重要甚至更重要的是：每天提及的有關任務+故事進展百分比+障礙列表的內容。過了一段時間，管理層和團隊成員並不太在意燒壞（或燒壞）。
Burndowns（或甚至「burn ups」）應該只有表示剩餘工作。
如果你已經完成了一個故事的一半，你不能發貨，它不計算。如果你在故事結束時完成了一半 - 如果你正在測量速度，那麼在它完成的任務不會計算在內。
只是圖表故事還剩待完成。
這是一個更嚴厲的措施，但沒有用的按摩數字 - scrum應該傳達壞消息，以便事情得到解決。
其餘爲Sprint burndowns 利用小時 - 在衝刺計劃，估計所有的工作，完成一個故事根據你的做 定義 - 每一天，開發人員和測試人員重新估算剩餘的所有他們的工作時間（改變向上或向下） - 通過剩餘時間跟蹤短跑燃盡 - Sprint要走多遠或好程度的一個很好的指標
這不適合發佈burndowns，因爲您不會分解積壓的所有故事，衝刺規劃研討會的下一個衝刺。因此，使用Story point burndowns（在計劃撲克會話期間由整個團隊派生的相對大小和複雜度值）。這是向您發佈進展的一個很好的指標。
根據我的經驗，你不能真正瞭解一個任務居然有多大貢獻一個故事。將它們繪製在刻錄圖上會造成錯覺。 – 2008-12-15 21:11:58
哦，當然有一種方法可以告訴他們隊伍是否坐在他們的拇指上：在隊伍中。或者至少參加每日Scrum。 – 2008-12-15 21:12:46