一個團隊/個人花 10 小時能完成的任務，另一個團隊/個人或許需要 100小時；

也有可能團隊花了 100小時但是什麼都交付不出來；

作為一個使用者故事，只有“完成”與“未完成”兩種狀態，不能使用一個百分比來表達“部分完成”，例如我們不能燃燒掉一個使用者故事 1/3 的故事點=來表達它已經完成 1/3了；

基於小時的估算是不精確的，不同人在同一個任務上要花不同的小時數；

花了幾個小時在一個任務上不等於這個任務有一部分被完成了， “部分完成”是一個隱藏問題的危險狀態，應該避免使用；

故事點估算更簡單和敏捷，雖然它很難使用。  

 
基於“小時估算”及基於“故事點”監控的差異，一直是一個具體而微妙的問題，令很多初涉敏捷的組織迷惑。（引用作者的用詞，）這真是一個“乾淨利落”的案例。 能正確使用“故事點”來估算及後續監控，理應不會出現任何異議。但學界也仍然有諸如Mike Cohn 等導師級人物仍認為 Ideal Hours是可用的。我個人的理解，其思路與作者有一點關鍵不同：在燃盡圖更新時，視角並不是記錄“已消耗工時”，而是再次估算“剩餘工時”。換個角度看，燃盡圖的更新體現了一個不斷估算的過程。再者，遵守“只有徹底完成的Task才能在燃盡圖上獲得分數”的規則，也可能有效的避免此問題。 個人體會:從 Burn down的價值取向分析，（徹底）完成了多少、（到底）剩餘多少，是重要的；既有的成本投入，不太重要。