故事和史詩的大小應(yīng)該使用故事點數(shù)【原注7】或是理想工作日估算出來，并按優(yōu)先級排序，這樣工作可以分配到各個迭代之中。版本發(fā)布規(guī)劃活動以產(chǎn)品負責人解釋待發(fā)布版本的目標開始。團隊討論在這樣的目標下，需要交付哪些東西，并表明在交付時需要考慮哪些因素。其他要考慮的因素包括風險，以及史詩和故事之間的依賴。高風險、高價值的功能特性應(yīng)該排高優(yōu)先級，以早日交付，這樣項目可以調(diào)整，以應(yīng)對風險是否會演化成嚴重問題（比如，我們掌握的技術(shù)無法做到我們期望的結(jié)果）。依賴關(guān)系也許會影響交付的順序（如果我們先完成這一塊，那一塊后面做起來容易了）。

版本發(fā)布規(guī)劃活動從團隊的速度開始，如果這是第一次版本發(fā)布，需要估算團隊速度，對于后續(xù)的版本發(fā)布，此前版本發(fā)布時的實際速度可以用來作為參考（除非團隊在版本發(fā)布之間發(fā)生巨大變動）。

剛開始只能猜測估算速度，要想得到更為準確的猜測，要花更長時間來得到結(jié)果。簡單的方式是：詢問團隊，讓他們估計自己能夠在一個迭代內(nèi)完成多少個故事點數(shù)，并在這個數(shù)字上做計劃。結(jié)果可能不準確，但是已經(jīng)可以作為好的起點。

要對團隊的交付能力有更好的估算，得使用更徹底的估算技巧，要知道想得到更準確的結(jié)果，得付出更多成本，而且付出的成本不一定能夠提供更多價值。James King在自己的網(wǎng)站上提供了一個有用的估算工具包，可供下載。

得到估算速度之后，可用其規(guī)劃迭代，步驟如下：

    按照優(yōu)先級順序，列出故事和史詩，并注明它們的故事點數(shù)大小。
    （根據(jù)估算活動）判斷一個迭代中可以交付多少故事點數(shù)。
    考慮團隊需要完成的非用戶故事工作可能產(chǎn)生的影響，比如在早期的迭代中，由于工具和工作環(huán)境不到位，工作效率會受到影響。
    向計劃中加入一個新的迭代。
    向迭代中加入故事，直到用掉所有的工作能力。
    詢問：是否所有的故事都已經(jīng)解決、版本發(fā)布目標是否達成。
    如果沒有，那么向計劃中加入新的迭代，并重復(fù)步驟5和步驟6.
    一旦所有的故事都已經(jīng)分配完成，與大家計劃進行交流，并征求他們的反饋，看看這些計劃是否現(xiàn)實并且可以完成。

這個流程可以通過下圖展示：

版本發(fā)布規(guī)劃是一個具備適應(yīng)性、可調(diào)整的計劃，它將會隨著項目推進而改變。一旦版本發(fā)布規(guī)劃完成，而且大家對之達成共識，它可以用來指導(dǎo)迭代中的工作。版本發(fā)布規(guī)劃也可以用來制作項目的初目標速度圖。

迭代規(guī)劃

在每個迭代的開始，團隊根據(jù)從已完成工作中得到的經(jīng)驗教訓、以及項目所處的更大環(huán)境，可以重新規(guī)劃項目剩余的工作。迭代規(guī)劃會議有兩個主要活動。

    驗證、更新版本發(fā)布規(guī)劃
    為當前迭代制定迭代計劃

第一個活動中，可以檢查當前的版本發(fā)布規(guī)劃，并根據(jù)自上次更新來發(fā)生的任何變化，更新當前版本發(fā)布規(guī)劃。迭代的開始，是敏捷項目調(diào)整的時候，基于項目環(huán)境的實際情況，可以改變規(guī)劃。