轉載地址：http://www.scrumcn.com/agile/scrum/4602.html

一輪迭代完成的故事點就是專案的速率。為這個專案做計劃時，我們可以用已知的速率，我們也可以自己假想一個速率。速率是一個有用的管理工具，所以在每輪迭代結束和迭代中監控團隊的速率是很重要的。

測量速率

多數故事很容易清點：團隊在迭代中完成了這些故事，所以他們的點數全部計算在內。假如一個團隊某個迭代中的速率是23。如果釋出計劃假定的速率和23差別很大，就有必要重新審視專案計劃。但是，注意不要過早地調整發布計劃。不僅僅因為是最初的速率往往不準確，而且速率在初期的迭代中也很不穩定。可能需要兩三個迭代之後，才能獲得一個長期的，比較穩定的速率。

但是不能將部分完成的故事也計算在速率中。

注意：不用實際小時作為速率。

計算速率是用迭代開始前分配的故事點數。一旦迭代完成，就不要改變迭代中團隊獲得的任何故事點數。舉個例子來說，假如一個故事估算是4個故事點，但其實更大。後來團隊發現他們應該估7個故事點。在計算速率時，這個故事應該算4個點，而不是7個點。

通常情況下，應鼓勵團隊在為下輪迭代計劃速率時，不要超過上輪迭代的速率。然而，如果團隊確實認為有個故事被嚴重低估，在下輪迭代中他們能做更多，就應該讓他們計劃一個稍微高一些的速率。

雖然團隊不能返回修改一個已經完成故事的點數，但他們應該用這類資訊調整後續故事的估算值。

計劃速率和實際速率

圖中畫的第三輪迭代的實際速率超過了第一輪的計劃速率。然而，第二輪和第三輪迭代的實際增長不如計劃，所以實際速率比計劃速率稍微低點。

圖11.1中的團隊如果按照第一輪迭代得出結論並告訴客戶他們超過了計劃速率可以將交付日期提前，那他們就錯了。那看看3輪迭代後怎樣？團隊是不是可以說他們應降低客戶對釋出計劃的期望？要回答這個問題，團隊不僅需要圖11.1中的速率圖，還有圖11.2中的累計故事點圖。

累計故事點圖表明瞭在每輪迭代結束時總共完成的故事點數。由此，我們可以在圖11.2中看出儘管第2輪迭代的進展比計劃緩慢得多，第2輪迭代結束後，團隊實際完成的點數還是比計劃的多。但是，在第3輪迭代結束後，團隊在第一輪迭代建立起來的優勢被第2輪和第3輪迭代的較慢進度蠶食殆盡。

在第3輪迭代結束後，團隊很有可能不能按照計劃完成那麼多的功能。如果客戶不能在每天與團隊的溝通中意識到這點，團隊應當及時讓客戶瞭解目前的狀況。

迭代燃盡圖

另外一個監控進展的好方法就是迭代燃盡圖（Burndown Chart）。迭代燃盡圖展示了以故事點表示的再每輪迭代末剩餘的工作量。圖11.3就是一個例子。

燃盡圖有一個有趣的特徵，既可以從中瞭解到用已完成的故事點表示的進度，也可以從中瞭解到對釋出剩餘計劃故事點數的改變。

從圖11.3中可以看到，團隊在第一輪迭代實際取得了負進度。我們不能從燃盡圖中得到團隊前進的速度。圖11.3中的團隊可能完成了90個故事點，然而可能增加了95個故事點。想知道團隊完成了多少故事點，應該看速率圖或累計故事點圖。

即使燃盡圖不能表示團隊的開發進度，但它還是很有用，因為它能更好地展現專案的整體進展。敏捷軟體開發的一個優點就是專案開始時不需要為專案需求寫冗長完整的說明。敏捷團隊都承認客戶不可能預先知道所有事情的事實。因此，敏捷團隊會要求客戶提供儘可能多的資訊，並允許客戶在專案過程中修改或精煉他們的想法，大家在一起學習如何構建軟體。也就是說不斷會有新故事湧現，也會有舊的故事因為變得沒有價值而被取消，故事的規模和重要性也會不斷進行調整。

迭代中的燃盡圖

燃盡圖不僅可以用於在迭代結束時跟蹤進展，它還是迭代期間一種很好的團隊自管理工具。在迭代中，每日燃盡圖可以展現在迭代內剩餘的估算小時。

NOTE：是剩餘小時，而不是花費的小時

注：本文來自於網友對《使用者故事與敏捷方法》(作者：Mike Cohn)一書的書摘