00.所有的项目都要经过一个启动阶段，无论它是一个用来讨论高层次需求的简单会议，还是一个更正式的阶段：神品、分析和设计，以及签署公测之前的详细信息。启动过程中传统的投入是指PRD(产品需求文档)，有些人说也指MRD(市场需求文档)。
01.一旦客户创建了产品概述文档，交付团队就需要与客户面对面沟通交流一遍理解、分解和估算功能特性。
*简单介绍、基本规则、审查的目的和议程（项目管理者）
*我们需要审查当前形势或现有产品导路图？（项目管理者，架构师，客户/产品负责人）
*我们的产品介绍是什么？它发生改变了吗？（客户/产品负责人）
*发布日期是什么时候？多少个迭代将产生这个发布？（项目管理者）
*这个发布的主题是什么？（客户/产品负责人）
*对这个发布，我们需要有哪些特性?(客户/产品负责人)
*我们做过了什么假设？我们处理那些制约因素(团队)
*里程碑或交付日期是什么？我们是否拥有LRM(最后责任时刻)决策点？（团队）
*团队（迭代速度）的能力是多少？(团队)
*我们可以将特性移植到迭代里吗？我们需要将他们分成更小的特性，以便可以在一个迭代中完成吗？（团队）
*我们有什么问题或忧虑呢？（团队）
*今天根据我们所掌握的资料，我们能够承诺这个发布版本吗？（团队）
敏捷项目管理者应该促进并且记录下在会议中出席那一些假设、关注点/风险、依赖关系、决定和行动。
02.
创建发布计划类似于建立一个项目时间表，但具体的任务、产品负责人和每小时评估在这个时候不能被及时标识。
04.迭代计划会议。一旦团队已经计划这次发布，该团队应开始其第一次迭代。为了计划这次迭代，团队应在迭代的第一天见面。
*简单介绍基本规则、审查的目的和议程?(项目管理者)
*我们知道迭代开始和结束的日期吗？（项目管理者）
*我们知道团队的开发速度吗？（团队）
*我们知道”完成“指的是什么吗？（团队）
*这次迭代，我们需要哪些特性？每个特性的验收标准是什么？（客户/产品负责人）
*我们是否拥有关于各个特性的足够信息，以便能够完成任务？（团队）
*我们能够评估那些任务吗？（团队）
*我们做了哪些假设？那些制约因素是我们正在处理的？依赖关系是否影响我们的优先级？
*我们受到开发速度的限制吗？（团队）
*我们有什么问题/忧虑呢？（团队）
*根据今天已经掌握的信息，作为一个团队，我们能够承诺这次迭代吗？（团队）
*结尾：下一步是进行开发工作。（项目管理者）
05.迭代计划
迭代计划会议的结果称为”迭代完成事项列表“，这是由团队的迭代目标和必须完成的迭代事项列表组成的。
06.迭代待完成事项列表
06.迭代过程结束
