每一輪迭代完成之後需要開迭代計畫會議為下一輪的迭代計畫。迭代計畫會議包括：1、討論故事；2、從故事中分解出任務；3、開發人員承擔每個任務的職責；4、以上3項完成之後每個開發人員對其任務量估計，盡量保證自己領取的任務在下輪迭代結束時可以完成。
討論故事：開發人員充分理解故事，在其中分解出任務；需要理清故事的關鍵細節。
從故事中分解出任務：因為乙個故事有可能由幾個程式設計師一起承擔，所以要將故事分級成更小的單位；而且分解任務的過程還可以發現以前被忽視的細節。
開發人員承擔每個任務的職責：開發人員自己領取想要承擔的任務，在專案中如果有人不能完成任務，其他人應該用於去承擔他的一部分任務。
估算並確認：每個人對自己承擔的任務進行故事點的估算，如果估算出來自己有可能完不成任務可以有3個選擇：1、接受事實；2、求助別人承擔自己的一部分任務；3、與客戶討論放棄乙個故事。
在迭代過程中通過開發人員的完成情況估計出專案的速率是乙個非常重要的度量，有了速率就便於隨時調整專案的進度。所以怎麼準確的測量出專案的速率就變得很重要。每一輪迭代的速率即迭代中完成的故事總點數（即通過驗收測試的故事的總點數，但是不能計算沒有完成的故事），往往要經過2~3輪迭代才會得到乙個長期的、相對穩定的速率。為了保證的速率的合理性以便更好的監控進展，可以監測實際速率和計畫速率的偏差、或者畫迭代燃盡圖（以故事點表示每輪迭代末剩餘的工作量）。
使用者故事以其獨有的特性在專案中發揮著作用，它不再是死板的文件中晦澀難懂的專業術語，而是記錄客戶對於功能的描述的對話。所以它相對於以往的需求方法有著很多的長處，而一些人對其有些誤解。
首先使用者故事不是ieee830：它的建議覆蓋了如何整理需求規則文件、角色原型和良好需求的特徵等主題最突出的特徵是「系統應該……」。這種需求方式乏味、容易出錯，而且非常費時，所以讀者會略過很多內容，導致讀者無法理解全域性。iee830描述的是需求列表，且需求成本不可見；而使用者故事描述的是使用者目標，從客戶角度關注新產品的目標而不是新產品的特徵列表，且每個故事開始都會有乙個估算，客戶知道團隊的速率，也知道每個故事的點數。其次使用者故事不是用例：用例是對系統之間以及乙個或多個使用者之間互動的一般性描述，使用者是使用者或另外的系統；使用者故事的範圍相對用例來說要更小一些；故事相對於用例的完整性也要小，用例相當於故事和驗收測試的集合；二者目的也不同，用例為了記錄客戶和開發團隊的協議而故事為了方便發布計畫和迭代計畫。最後使用者故事不是場景：場景包含更多的細節，通常涵蓋多個故事。
使用者故事雖然不是最好的需求方法但相對於其他需求方法範圍更小，而且其對客戶可見，所以客戶便於可以計算出專案的速率便於獲取專案的進展情況。
使用者故事與敏捷開發方法筆記06
使用者故事得到這麼多人的肯定，是因為它自身的優勢有很多 1 使用者故事強調口頭溝通，因為傳統的通過各種文件進行表達，每個人對於文字的含義的理解都不同，所以在閱讀文件的過程中可能會因為理解的不同對專案的完成造成影響 2 人人都可以理解使用者故事，並且使用者故事可以增強人們對各種事件的記憶 3 使用者故...
使用者故事與敏捷開發方法筆記01
軟體需求是乙個軟體專案成功的關鍵因素，許多軟體專案失敗都是因為軟體需求的 不完整 不準確 不一致 而軟體需求是從業務需求經使用者需求最終得到系統需求的，所以業務需求是軟體需求的源頭，而業務需求又是從客戶業務中來的，客戶有問題且需要解決的業務才是業務需求。所以準確 完整的根據使用者的描述獲取使用者的業...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...