追蹤頻率
在敏捷迭代追蹤中，團隊成員會按照既定的追蹤計劃，記錄他們目前正在進行的任務的追蹤資訊。團隊可以選擇每日、每週、每週兩次，或任何最符合自身資訊需求的頻率。每日記錄追蹤資訊可以確保：1）資訊在大家記憶猶新時輸入；2）項目圖表能夠及時更新。許多團隊會在迭代的最後一周之前每週追蹤一到兩次，之後會提高資訊輸入頻率，以確保整個迭代期間的每日進度可見度。這些訊息中的大部分也應該在每日站會上進行溝通。因此，查看追蹤圖表可能會取代每日站會中一些重要的溝通環節。
功能完成狀況與任務完成狀況
當一項功能的所有任務都完成後，該功能就被視為已完成。有些團隊可能還會要求所有驗收測試也必須通過。
常見問題
為什麼要追蹤迭代？
對於極短的迭代週期（例如一周），衡量階段性狀態的必要性會降低；但即使是一周的迭代周期，了解工作在迭代中期是否完成一半，以及自初始迭代計劃以來可能新增了多少工作，仍然非常重要。隨著迭代周期的延長，準確了解工作狀態的必要性也隨之增加。
迭代過程中會追蹤哪些資訊？
迭代過程中需要追蹤的資訊非常少。對於每個任務，只需定期追蹤已投入的工作量和剩餘工作量估算即可。驗收測試的狀態也需要追蹤。 Scrum 忽略已投入的工作量，將迭代追蹤的重點完全放在剩餘工作量估算。
誰輸入追蹤資訊？
通常情況下，每個人都會輸入自己的追蹤資訊。有些團隊會選擇在每次迭代中指定一名成員負責收集和更新團隊的所有追蹤資料。
團隊成員多久輸入一次工時？
每個組織都會制定自己的追蹤計畫。團隊的追蹤頻率通常從每天到每週不等，也有更長的迭代周期。
在迭代過程中是否應該更改估算值？
估算只是估算而已。有些任務會提前完成，有些會延遲完成，而且通常會出現新的任務。我們的目標是持續的一致性和可靠性，而不是估算的精確度。如果一個團隊每次迭代都能穩定地交付相當於 20 個理想工作日的功能，那麼通常情況下，任務估算會在 200 到 220 小時之間，這足以讓我們準確地規劃和管理專案。如果追蹤實際工時，每次迭代的實際工時可能達到 260 小時。因此，鑑於我們使用歷史驗證過的估算來進行規劃，而不是使用實際工時或預測工時，就沒有必要回頭修改估算了。
如果剩餘的工作量超過了任務的最初估計怎麼辦？
如果情況屬實，那麼就輸入這些資料。這在某些任務中是客觀存在的，我們的目標是用追蹤資訊來呈現實際情況，而不是某種理想化的結果或計算結果。
為什麼不直接計算剩餘努力量呢？
計算出的數字並不能代表任務或專案的真實狀態，它們只是一種數學計算，而歷史經驗表明，這種計算方法並不可靠且不準確。為了準確傳達任務狀態，團隊成員應該始終根據現有所有資訊來評估剩餘工作量。
如何判斷一項任務何時完成？
當任務中的所有人都已完成所有工作時，該任務就完成了。
如何判斷一個功能何時完成？
當一個功能完全沒有剩餘工作要做，並且該功能已被客戶接受時，該功能就完成了。
在一次迭代結束時，如果某個功能只完成了一部分怎麼辦？
如果某個功能只完成了一部分，那麼是否應該拆分、移到下一個迭代、重新調整優先順序等等，都由客戶來決定。敏捷開發通常被認為是非常二元的，要么交付了價值，要么沒有交付。如果工作完成了，但沒有交付任何業務價值，那麼敏捷開發就認為這是個大失敗。如果該功能可以拆分，一部分價值在當前迭代中交付，另一部分價值在後續迭代中交付，那麼這最終由客戶和團隊共同決定。
