項目不斷進行時，需要詳細規劃即將實施的迭代活動。在當新月異的環境中，提前幾個月甚至幾年做詳細規劃是毫無價值的，但您可以對下幾周（典型的迭代的時間跨度）進行成功地詳細規劃。
項目規劃的普遍且難以置信的有效方法是從粗略的項目規劃開始（請參閱“項目規則技巧”），即從項目開始時開發，然后在完成構成項目的各種迭代時緩慢發展形成。隨著項目不斷進展，需要更新整個粗略的項目規劃，更新它以反映近來努力的實際成果以及您的團隊將繼續從事的下一個（或兩個）迭代的規劃細節。在為單一迭代開發細致的規劃時，應該執行這些步驟。
實行真實性檢查
通過詢問并且回答一些難題來開始詳細的規劃工作：項目是否仍在按計劃進行？您的方法是否仍有意義？您的團隊是否由合適的人員組成？您是否仍有資金管理者支持？如果其中任何一個問題的答案是否，則需要解決問題，這可能意味著新（且非常短）迭代使您的團隊回到正常軌道上。對處于困境的項目進行大計劃是毫無價值的。
標識詳細的任務
在項目開始時，體系結構和轉移迭代只是列出需要實現的任務列表。然而，要規劃迭代，必須評估已為它指定的需求（請參閱“基于需求的規劃策略”）。隨著項目發展，您將對于對個別需求有更好理解。您可能會發現，現在需要更改給迭代指定的原始需求，這些需求初是有意義的�；蛟S已經標識并添加了新的需求；或許已經擴展或縮減了需求；或許已經更改了優先級。不管什么原因，您會發現您需要重新定義打算在該迭代中實現的內容。根據需求，標識需要實現的任務。
標識任務相關性
某些任務取決于其它任務。例如，在部署源代碼之前，必須先編寫它。測試案例的開發可以在編碼之前開始。實際代碼的測試必須等待，直到已經編寫了某些代碼（盡管或許不是所有代碼）為止。問題是某些任務必須在其它任務完成之后才能開始；某些任務必須等待，直到另一個任務開始了為止，它才可以開始；某些任務不能完成，直到另一個任務完成為止；某些任務不能完成，直到另一個任務開始了為止。
均衡資源
需要緊記的重要事情是，每個人一次只可處理那么多任務，并且在工作的那只有那么多時間。這個概念稱為資源均衡，確保任務分派是合理的。 指定用 10% 的時間完成 10 項任務很可能無法完成任何任務， 而且指定用 50% 的時間完成 5 項任務的人員也不可能完成這些任務。確保現實的規劃的好方法是，讓執行計劃的人員參與計劃開發。
保持迭代短小
迭代周期應該保持比較短。應該將大于 8 周的迭代分割，以便讓您迅速將軟件交付給用戶。因為正在嘗試彌補在先前迭代中跳過的工作（如文檔編制），或者因為您的需求正在增加而沒有添加新的迭代來反映這一事實，所以當項目進展時迭代長度增長是一種趨勢。執行真實性檢查并按照它們的結果行動，將幫助您使迭代周期保持簡短。
考慮并行開發
分幾個子團隊來同時進行系統的不同部分始終是一種有效的辦法，尤其對于系統縱向片段的開發。并行開發可以大大地縮短產品的上市時間，這是當今高度市場競爭性的一個重要因素，盡管它以增加協調工作為代價。共同的體系結構、共享知識視野、共同的開發實踐、定期團隊會議及共享工作場地使并行開發成為可能。
