每一轮迭代完成之后需要开迭代计划会议为下一轮的迭代计划。迭代计划会议包括：1、讨论故事；2、从故事中分解出任务；3、开发人员承担每个任务的职责；4、以上3项完成之后每个开发人员对其任务量估计，尽量保证自己领取的任务在下轮迭代结束时可以完成。
讨论故事：开发人员充分理解故事，在其中分解出任务；需要理清故事的关键细节。
从故事中分解出任务：因为一个故事有可能由几个程序员一起承担，所以要将故事分级成更小的单位；而且分解任务的过程还可以发现以前被忽视的细节。
开发人员承担每个任务的职责：开发人员自己领取想要承担的任务，在项目中如果有人不能完成任务，其他人应该用于去承担他的一部分任务。
估算并确认：每个人对自己承担的任务进行故事点的估算，如果估算出来自己有可能完不成任务可以有3个选择：1、接受事实；2、求助别人承担自己的一部分任务；3、与客户讨论放弃一个故事。
在迭代过程中通过开发人员的完成情况估计出项目的速率是一个非常重要的度量，有了速率就便于随时调整项目的进度。所以怎么准确的测量出项目的速率就变得很重要。每一轮迭代的速率即迭代中完成的故事总点数（即通过验收测试的故事的总点数，但是不能计算没有完成的故事），往往要经过2~3轮迭代才会得到一个长期的、相对稳定的速率。为了保证的速率的合理性以便更好的监控进展，可以监测实际速率和计划速率的偏差、或者画迭代燃尽图（以故事点表示每轮迭代末剩余的工作量）。
用户故事以其独有的特性在项目中发挥着作用，它不再是死板的文档中晦涩难懂的专业术语，而是记录客户对于功能的描述的对话。所以它相对于以往的需求方法有着很多的长处，而一些人对其有些误解。
首先用户故事不是IEEE830：它的建议覆盖了如何整理需求规则文档、角色原型和良好需求的特征等主题最突出的特征是“系统应该……”。这种需求方式乏味、容易出错，而且非常费时，所以读者会略过很多内容，导致读者无法理解全局。IEE830描述的是需求列表，且需求成本不可见；而用户故事描述的是用户目标，从客户角度关注新产品的目标而不是新产品的特征列表，且每个故事开始都会有一个估算，客户知道团队的速率，也知道每个故事的点数。其次用户故事不是用例：用例是对系统之间以及一个或多个用户之间交互的一般性描述，使用者是用户或另外的系统；用户故事的范围相对用例来说要更小一些；故事相对于用例的完整性也要小，用例相当于故事和验收测试的集合；二者目的也不同，用例为了记录客户和开发团队的协议而故事为了方便发布计划和迭代计划。最后用户故事不是场景：场景包含更多的细节，通常涵盖多个故事。
用户故事虽然不是最好的需求方法但相对于其他需求方法范围更小，而且其对客户可见，所以客户便于可以计算出项目的速率便于获取项目的进展情况。