在Scrum中，整个团队会举行计划会议，以决定接下来的这个Sprint会做哪些事情，决定由PO和整个团队来做，依据就是优先级。PO会去选择那些从他的角度看优先级最高的，在上个Sprint已经完成工作的基础上，从Product Backlog中新添加那些对于软件用户来说最具优先级的特性，来交给团队实现。这里当然会有特别的情况，比如会有新添加的特性需求，也会有上个Sprint未完成的功能，还会有个别需要去掉的需求，需要PO在这里统筹安排，并和团队一起协商，达到一个最优化的选择和决定。

然而这里说的不是泛泛的迭代计划该怎么做，而是第一个迭代的计划该怎么做，根据什么依据或者原则来决定第一个迭代做哪些故事，我们会看到这里需要有更多的考量因素。

• 可以组成MVP的那些故事。也有书里把MVP叫做MMF的，反正就是能够组成目前所要构建系统的最小价值组成。有个极端的例子，虽然当前需求的系统有很大的预算，也预见可以做一年，但突发情况要求只有一个迭代的时间，团队需要思考，从那么多需求中如何梳理出客户所需要的，真实的最基本的那些功能，能在一个迭代里面就可以交付的价值。这也是为客户负责，钱花得值，团队的努力有所回报而考虑的。可以认为从第二个迭代开始，从product backlog里面选取的故事，都是在丰富和扩充MVP。
• 可以建立系统基本架构的那些故事。把那些有可能搭车系统的最基本架构的故事挑出来，这样最大的好处在于，能够尽早发现基础架构可能存在的问题，设计的问题，尽早避免在很久以后发现问题时，进行修补所带来的更大的代价。
• 可能是技术难点和风险的故事。这些故事要尽早去做，从设计到开发到测试，把比较难的风险大的特性需求尽早完成，一直是TW团队所追求的，初衷同样是尽早消除这些技术难点和风险，并同时避免开发晚期遭遇这些技术难点和风险时，所招致的更大代价。
• 找出处于依赖关系最底层的那些故事。也有可能是彼此间较少甚至没有依赖的故事，选择这些故事的目的在于，在迭代进行中可以不会因为故事之间的强依赖而发生开发或者测试依赖的问题。存在依赖关系的故事，可以放到先后不同的迭代里面来完成。
• 可以让团队每个人都有活干。这一点的目的在于，选择出满足上一点的处于依赖最底层的故事后，还要确保能够并行开发的故事，就是每一对pair都能从迭代的第一天开始故事的开发，而不是有依赖和等待。这一点是对上一点的进一步优化。
• 尽量可以让团队在第一迭代完成的故事。这会是一个估算的结果，但也是建立团队信心的需要。需要一个预测的点数，来成为以后估算出团队速率的基础值，这在选择第一个迭代的故事时，很重要的一个考量。

每一个迭代的计划过程，都是根据团队的实际情况，根据一些需求和因素来选择合适的故事进入开发流程。但对于第一个迭代来说，需要的考虑的因素稍微多一点。如上所述，每个因素间根据团队自己的特点和实际情况，会有所侧重，但结果期望会是一个相对正确的选择。