特徵選擇（衝刺計畫——第一部分)
許多團隊會為迭代設定總體目標，以指導功能選擇。在會議開始時，通常會從發布計劃中選出優先順序最高的功能。如果迭代本身就有總體目標，那麼一些優先順序較低的功能如果更符合該目標，也可以被選取。事先了解迭代速度對於團隊安排合理的工作量至關重要。
例如，如果團隊之前計劃完成 40 個故事點的產品功能，但最終只成功交付了 30 個故事點，那麼 30 個故事點就應該被視為下一個迭代的當前速度。將過去的速度預估與實際數字進行比較，在迭代等級、功能層級和任務層級都非常有用。所有這些都有助於團隊確定他們在下一次迭代中可以承擔多少工作。如果迭代任務超額完成，則客戶需要選擇哪些功能需要推遲到未來的迭代。 迭代計劃 在會議上，客戶將與團隊討論產品功能，並嘗試回答團隊提出的任何問題。
任務規劃（衝刺計畫——第二部分)
團隊會將功能分解成任務。開發人員隨後認領任務並進行估算。任務時間通常從四小時到兩天不等，大多數任務都可以在一天內完成。超過兩天的任務通常應該分解成更小的任務。有時在任務規劃過程中，會發現某個功能在最初的估算中被嚴重低估了。 發布計劃在這種情況下，團隊需要與客戶合作，提供更正的估價，並確定哪些功能可能需要因此而延遲。
迭代調整
在迭代過程中，如果所有功能交付完成後還有剩餘時間，團隊可以請客戶提出需要新增到本次迭代中的其他功能。另一方面，如果顯然無法交付所有功能，團隊則與客戶合作，確定哪些功能可以延遲交付或拆分，以便在迭代截止日期之前交付最大價值。
警告標誌
- 如果經過一系列迭代，團隊不斷將功能推向未來，這表明團隊應該更加關注其先前的速度，以最大限度地減少持續的超額預訂並最大限度地提高計劃的準確性。
- 如果團隊每次迭代都不斷推出相同的功能，這可能表示團隊有意迴避某些功能，應該探討其根本原因。
- 如果團隊過於注重細節，並對每個功能進行完整設計，那麼或許可以更專注於確定必要的任務工作。
常見問題
如何處理任務之間的依賴關係？
這個問題經常被問到。作為迭代計劃的一部分，團隊在劃分功能時應該努力減少任務之間的依賴關係。 Mike Cohn 的優秀著作中有很多具體的技巧。 應用程式使用者故事接下來，團隊應努力協作，盡可能減少不可避免的依賴關係的影響。敏捷團隊通常採用簡單、鬆散耦合、可適應的設計，以最大限度地減少依賴關係。鮑伯馬丁的開創性著作是設計和改進此類架構的絕佳資源。 敏捷軟體開發：原則、模式與實踐敏捷團隊也會使用各種技術、工具和實踐，使他們能夠同時處理相互依賴的子系統和模組。 測試驅動開發自動化測試框架和模擬物件有助於團隊最大限度地減少和應對任務間的相互依賴關係。持續密切的協作至關重要；集中辦公的團隊更容易在整個迭代過程中及時解決依賴關係的難題。
迭代周期有限，因此單一潛在依賴項導致專案失敗的風險較低。 PERT 圖和 CPM 雖然在系統整體理解方面可能很有價值，但在高速迭代的軟體開發壓力下極易失效。為兩週的迭代周期建立依賴模型所花費的額外時間和精力往往得不償失。自動化測試和程式碼至少能以相同的速度提供更準確、更可執行的回饋。
團隊成員應該報名參加多少活動？
團隊成員很少會承擔超過上一迭代中能夠完成的任務總量的估算值。如果在迭代規劃階段沒有進行任務分配，那麼就需要更加重視確保團隊不會承擔過多的工作，方法是將其與上一迭代的功能和任務開發速度進行比較。
如果團隊規模不固定，如何規劃迭代？
如果無法依靠團隊的持續努力，任何專案方法，無論是敏捷的還是其他的，都難以提供有效的洞察。然而，在迭代軟體開發中，至少通常會累積一些歷史數據，作為規劃的基礎。例如，假設你之前帶領一個十人團隊完成了幾個迭代版本，平均每個迭代版本耗時 20 個理想工作日（或 200 小時），而現在團隊人數減少了一半，那麼簡單的計算就能讓你在即將到來的迭代中（至少在初期）將理想工作日的規劃控制在 10 個以內。如果關鍵人員已經離職，或者你發現自己的規劃有誤，你將在接下來的幾週內發現問題，並能夠迅速調整以適應未來的迭代。
如何計算間接費用（會議、電子郵件等）？
團隊通常不會花太多時間追蹤一些細小的開銷。經過幾次迭代後，這些幹擾會反映在越來越穩定（儘管有時出乎意料）的實際開發速度上。有些團隊會將較大的干擾和突發事件明確地納入迭代計劃，以降低風險並提高透明度。
在迭代規劃階段，如何考慮缺陷修復？
團隊處理缺陷修復的方法有很多。最簡單的方法之一是將缺陷作為明確的輸入納入迭代計劃，對其進行優先排序，並估算相關任務。在計畫層面，缺陷和功能本質上是等效的工作單元。有些團隊選擇在迭代流程之外單獨追蹤缺陷。這種方法風險更大：如果缺陷修復工作量在不同迭代之間有所變化，那麼團隊的開發速度也會隨之變化，進而影響估算和計畫。但如果缺陷修復工作量維持不變，那麼這種方法也能達到不錯的效果。
為什麼迭代次數必須永遠相同？
迭代周期長度相同或非常接近，為團隊提供了進行估算和計劃所依賴的節奏。如果沒有固定長度的迭代週期，就很難實現和衡量穩定的速度。在迭代結束時停止生產，這種紀律能夠讓所有人集中精力，促使設計保持簡潔，避免過度設計或範圍蔓延。整個組織很快就會習慣於輸入、計劃、執行、輸出和回顧的穩定節奏。如果沒有這種節奏，團隊效率就會降低。偶爾，為了配合截止日期、重大干擾或假日，可能會有合理的理由延長或縮短某些迭代周期。但這應該是例外，而不是常態。
如何計算測試和文件編寫時間？
測試和文件更新應該像其他任何需要開發人員投入時間的重要活動一樣，進行優先排序、預估和規劃。它們通常作為特定功能下的任務創建，但也可以單獨作為一個功能進行管理。
在迭代計劃階段是否應該修改功能預估？
只有當發現原始估算嚴重偏離實際情況，並且新的工作量會對團隊完成其他工作的能力產生重大影響時，才應該在迭代計劃期間修改功能估算。
在迭代過程中是否應該修改任務估算？
一旦迭代計劃完成，最初的任務估算就不應該再修改。另一方面，未來迭代的估算應該不斷修訂，以準確反映剩餘工作量。
所有團隊都應該採用相同的迭代計劃嗎？
所有團隊採用相同的迭代計劃有其優勢。只有當所有團隊採用相同的計劃時，總結跨團隊的迭代狀態才有意義。將剛開始迭代的團隊與即將結束迭代的團隊的數值狀態匯總在一起毫無意義。所有團隊採用相同迭代計劃的缺點在於，所有迭代的開始和結束時間可能會重疊。如果專案之間共享公共資源（例如客戶或管理層），他們可能會更傾向於採用錯峰迭代計劃。
