为了延续整个系列的行文思路，我也会涉及一些我们团队计划sprint的方法以及sprint过程中发生的 事情，并穿插着回答你们提出的那些问题。
首先，我想说的是，不存在敏捷无需计划的神话。可是，敏捷开发中的计划的确和传统软件开发中的 计划有着很大区别。正如我在上一篇博文中所说，我们针对利益攸关方(stakeholders)给出的上层需求创 建了带有优先级的产品待开发事项(product backlog)。这一带有优先级的任务列表形成了最基本的 sprint计划。在这一过程中，我们一般遵循三阶段的步骤：在主管间进行的预计划阶段，所有团队成员都 参加的计划阶段以及包含利益相关者的计划提交阶段。这里的关键是：计划是在所有成员的通力合作中进 行，最重要的是由组员自发来制定标准、而不是依赖于某个项目经理。
预计划阶段在上一个sprint的最后一周进行，在这一阶段中，团队中分别带领项目经理，开发和测试 的几位主管会聚集到一起讨论出在即将进行的下一个 sprint中，需要开发的故事(story)列表。这个过程 取决于很多因素，其中最重要的是：上一个sprint的进展情况，从利益相关者那里得到的反馈，需求或故 事优先级发生的变化以及预计的团队速度。项目经理(有时甚至是开发人员或者测试人员)在阐述故事的时 候会尽量简短到只描述出目标、故事的简单介绍以及故事的具体流程。我们发现OneNote很好的满足了我 们这一需求(稍后会给出一个故事的截图)。
产品待开发事项总是列出对客户有价值的条目，同时它也可以增加这个团队要求的条目。但是，只有 那些最终会给客户带去价值的条目才可以出现在待开发事项中。举例来说，创建并维护一个持续集成服务 器以持续保证最终产品的质量，这样的条目被允许出现在待开发事项中的。
计划阶段通常在sprint的第一天进行。在开会前，项目经理会把OneNote页面的链接发送给组员，以便 大家评估，并且为计划会议做好准备。通常，组员会在OneNote页面中交换意见，从而在会议之前澄清那 些不明了的地方。在计划会议当天，团队组员会聚集到一起，过一下所有的故事，解决之前发现的任何问 题，把故事进一步细分成一些任务，并描述每个故事的验收测试。组员同时也会对完成这些故事所需要的 时间做一个大致的估计，然后根据这些估计决定在这个 sprint中，团队可以完成哪些故事。
计划提交阶段在之后的一天进行，主管会再度聚集在一起并且向利益相关者介绍团队承诺完成的任务 。此时，利益相关者可以提出建议对优先级进行调整。比如，如果团队成员可以完成故事A，B以及C，但 是不能完成D和E，利益相关者可以建议团队在这一个sprint中完成A,B,D以及E(假设D和E消耗的总时间和C 相同)。然后，项目经理会把这些故事输入用来管理我们项目的Visual Studio Team Foundation Server 。
注：我们花了好几个sprint来学习并总结出以上这个计划流程。这就是sprint回顾(我会在以后的博文 中提及)发挥的重要作用。