故事和史詩的大小應該使用故事點數【原注7】或是理想工作日估算出來，并按優先級排序，這樣工作可以分配到各個迭代之中。版本發布規劃活動以產品負責人解釋待發布版本的目標開始。團隊討論在這樣的目標下，需要交付哪些東西，并表明在交付時需要考慮哪些因素。其他要考慮的因素包括風險，以及史詩和故事之間的依賴。高風險、高價值的功能特性應該排高優先級，以早日交付，這樣項目可以調整，以應對風險是否會演化成嚴重問題（比如，我們掌握的技術無法做到我們期望的結果）。依賴關系也許會影響交付的順序（如果我們先完成這一塊，那一塊后面做起來容易了）。
版本發布規劃活動從團隊的速度開始，如果這是第一次版本發布，需要估算團隊速度，對于后續的版本發布，此前版本發布時的實際速度可以用來作為參考（除非團隊在版本發布之間發生巨大變動）。
剛開始只能猜測估算速度，要想得到更為準確的猜測，要花更長時間來得到結果。簡單的方式是：詢問團隊，讓他們估計自己能夠在一個迭代內完成多少個故事點數，并在這個數字上做計劃。結果可能不準確，但是已經可以作為好的起點。
要對團隊的交付能力有更好的估算，得使用更徹底的估算技巧，要知道想得到更準確的結果，得付出更多成本，而且付出的成本不一定能夠提供更多價值。James King在自己的網站上提供了一個有用的估算工具包，可供下載。
得到估算速度之后，可用其規劃迭代，步驟如下：
按照優先級順序，列出故事和史詩，并注明它們的故事點數大小。
（根據估算活動）判斷一個迭代中可以交付多少故事點數。
考慮團隊需要完成的非用戶故事工作可能產生的影響，比如在早期的迭代中，由于工具和工作環境不到位，工作效率會受到影響。
向計劃中加入一個新的迭代。
向迭代中加入故事，直到用掉所有的工作能力。
詢問：是否所有的故事都已經解決、版本發布目標是否達成。
如果沒有，那么向計劃中加入新的迭代，并重復步驟5和步驟6.
一旦所有的故事都已經分配完成，與大家計劃進行交流，并征求他們的反饋，看看這些計劃是否現實并且可以完成。
這個流程可以通過下圖展示：
版本發布規劃是一個具備適應性、可調整的計劃，它將會隨著項目推進而改變。一旦版本發布規劃完成，而且大家對之達成共識，它可以用來指導迭代中的工作。版本發布規劃也可以用來制作項目的初目標速度圖。
迭代規劃
在每個迭代的開始，團隊根據從已完成工作中得到的經驗教訓、以及項目所處的更大環境，可以重新規劃項目剩余的工作。迭代規劃會議有兩個主要活動。
驗證、更新版本發布規劃
為當前迭代制定迭代計劃
第一個活動中，可以檢查當前的版本發布規劃，并根據自上次更新來發生的任何變化，更新當前版本發布規劃。迭代的開始，是敏捷項目調整的時候，基于項目環境的實際情況，可以改變規劃。
