在完成第一次迭代之前，有一些簡單的指南可以幫助您估算 Scrum 團隊的初始速度（請參閱下方的常見問題解答），但之後您應該使用經過驗證的歷史資料來規劃功能。通常情況下，速度會在短時間內趨於穩定，並為提高敏捷專案近期和長期規劃的準確性和可靠性奠定堅實的基礎。 敏捷交付 週期非常短，因此速度會迅速顯現，並且可以在專案早期得到驗證，然後依靠速度來提高專案的可預測性。
速度真的就這麼簡單嗎？
是的不要試圖把速度的概念複雜化──它其實很簡單，其價值很大程度上就在於它的內在簡潔。許多管理者和團隊對於速度的概念都比較陌生。 敏捷方法 人們往往過度分析速度的概念，並賦予它過多的複雜性。經過幾個月的敏捷專案實踐後，大多數人會對速度有「頓悟」的理解，摒棄之前與之相關的任何偏見，並欣賞它的簡潔性和內在價值。
速度圖
除了發布和迭代燃盡圖之外，衡量敏捷團隊的速度已被證明能夠極大地洞察專案進度和狀態。速度圖顯示了所有迭代中已交付工作量的估算總和。通常情況下，除非專案團隊組成發生較大變化或迭代周期變化，否則速度會在專案生命週期內保持穩定。因此，速度可以用於未來的規劃。雖然速度通常對未來幾個迭代周期比較可靠，但如果您接受優先順序、目標和團隊可能會隨時間變化，導致對未來某個迭代週期的置信度降低，那麼速度也可以用於規劃更長遠的發布週期。
對於初次接觸敏捷軟體開發的團隊來說，最初應該直接上手，並根據現有的指南和資訊選擇一個初始速度。速度可以很快（甚至快到下一次迭代）進行衡量和調整。速度，結合細粒度的功能（例如使用者故事、待辦事項清單、需求等）以及高層次和/或相對估算（以點數、理想天數甚至小時為單位），能夠大幅簡化和加速整個專案計劃、估算、狀態追蹤和報告流程。
敏捷 Scrum 常見問題解答
如何計算速度 敏捷開發 團隊計算過嗎？
速度是每次迭代中已交付（即已接受）功能的估計值的總和。
速度的計量單位是什麼？
速度的衡量單位與功能估算的單位相同，無論是故事點、天數、理想天數還是 Scrum 團隊交付的小時數——所有這些都被認為是可接受的。
如何估算第一次迭代的速度？
對於敏捷團隊的首次迭代，一個通用的指導原則是將初始速度規劃為可用時間的三分之一。如果您估算的是理想程式設計師時間，那麼這其中就包含了會議、郵件、設計、文件撰寫、重工、協作、研究等等。例如，假設有六名程式設計師，迭代週期為兩週，那麼總共有 60 個程式設計師工作日（6 名程式設計師 x 10 天）。在這種情況下，一個好的開始是在迭代周期內規劃 20 個理想工作日的工作量。如果使用實際時間，則需要預留足夠的緩衝時間來應對標準的專案管理成本：1）額外開銷；2）估算誤差。此外，請記住，速度會在首次迭代中迅速顯現。如果低估了速度，隨著新功能的加入，首次迭代的速度將會提升；如果高估了速度，隨著功能的移除，速度將會下降。對於第二次迭代，Scrum 團隊應該以首次迭代為指導。
會議、電話、電子郵件是否計入工作效率？
這取決於這些項目是否被估算並包含在內。 迭代計劃它們通常不包含在內——速度的目標是在敏捷團隊交付能力方面，在迭代過程中保持相對的一致性和可預測性。
敏捷開發團隊或專案的速度是否應該累積？
速度是一個非常局部化的衡量標準。除了團隊成員的個性各異之外，專案通常在估算方法、詳細流程、技術、客戶參與度等方面都具有獨特的特質。因此，這會導致全公司範圍的分析非常不準確。另一方面，如果你的所有團隊都採用完全相同的估算方法、開發流程、測試方法和追蹤方法，那麼你很可能就是個例外。
如果速度有波動呢？
速度通常會在合理的範圍內波動，這完全沒問題。如果速度波動幅度過大，並且持續超過一到兩個迭代週期，Scrum 團隊可能需要重新評估和/或重新協商。 發布計劃.
速度穩定下來需要多長時間？
對於大多數敏捷開發團隊來說，開發速度通常會穩定在 3 到 6 次迭代之間。
如何估算未來迭代次數？
未來的迭代會利用團隊過往的成功經驗來判斷團隊的能力極限。因此，速度是規劃未來迭代的適當指標。
如果專案團隊規模發生變化，我該如何估算專案進度？
敏捷開發速度的提升取決於團隊的穩定性。如果你的敏捷團隊發生變動，在規劃未來的迭代時，要運用常識。如果團隊中有 20% 的成員在幾個迭代週期內無法參與，那麼就將計畫速度降低 20% 左右。如果這其中包括幾位關鍵成員，特別是可能不太方便參與的客戶，那麼就需要進一步降低預估速度。只需下一個迭代周期，就能更了解團隊的交付能力，從而確定新的速度。
最高速度是否意味著最高生產力？
絕對不是。為了追求速度最大化，團隊實際上可能會適得其反。如果被要求最大化速度，團隊可能會偷工減料，減少單元測試或驗收測試，降低與客戶的協作，放棄修復缺陷，減少重構，或忽略敏捷開發實踐中的許多其他關鍵優勢。雖然這樣做可能帶來短期效益（如果可以稱之為效益的話），但從長遠來看，將會產生負面影響。我們的目標不是最大化速度，而是隨著時間的推移實現最佳速度，這需要考慮許多因素，包括最終產品的品質。
如果迭代次數變化，我們要如何測量速度？
你不能，至少沒那麼容易。速度的價值在於其固有的穩定性。固定的迭代周期有助於維持專案可靠的節奏。如果沒有這種節奏，你就需要不斷地修改、重新估算和調整，而且由於結果不穩定，預測未來的能力也會大大降低。另一方面，如果幾乎所有人都要休假一周去度假，或者因為公司會議要休假幾天，那麼當然可以運用常識，相應地調整迭代日期或速度。就像大多數敏捷實踐一樣，這些只是指導原則，而不是硬性規定。
