重新讨论项目的资源分配。识别缺口，需要的话，启动招聘或重新分配资源。同团队讨论，谁将扮演什么角色，并得到他们对职责的认可。

团队为每个工作项粗略的估算其规模。

同利益相关人讨论确定在项目约束中开发什么是现实的。使用利益相关人优先级和来自团队的估算来指导这些讨论。

团队识别风险，对风险进行量化分析以确定它们的优先值，并更新 [项目风险]。项目经理帮助团队决定哪些风险需要他们应对，哪些风险需要观察。

对风险的响应包括避免或缓解风险、探索的机会、或增加风险正面影响的概率。依赖于具体的情况，可能需要在 [项目工作] 中增加或删除工作项，以保证对风险的响应在团队的项目工作中被优先考虑和处理。对所有识别的风险进行响应是不可行的，因此团队需要决定需要处理哪些风险。在风险列表中保留以观察这些风险，并和利益相关人进行沟通。仅当它们发生时决定行动。

定义迭代的长度并使用它来获取速率目标。每个迭代中交付的工件数量决定了团队的生产速度，这对它们每一项进行估算。

如果是特征驱动的项目，团队使用 [项目工作] 以及速率目标来预测完成项目所需的迭代数量。如果项目是数据驱动的，那么团队估计在给定的时间窗内可以完成的工作数量（使用已知的团队生产率）。去掉范围外的工作，它们可以在未来的版本中考虑。

团队不应该在此计划上花费过多的时间。项目计划文档应该仅包括项目里程碑概述和每个迭代的1~3个目标。不要将个人的工作项放入此计划中，因为将导致过多的重计划。此计划的目标是创建一份高层的计划，描述团队如何在给定的系列迭代中构建应用。更详细的计划将通过贯穿项目的其它计划会议（例如，迭代策划）得到。后续，依赖于你从执行迭代的过程中所学到的，可能需要调整此计划。

将迭代安排在系列的阶段中。项目生命周期中的每个阶段以一个里程碑结束，里程碑旨在为利益相关人提供对项目的监督和控制机制，包括项目资金、范围、暴露的风险、提供的价值、以及过程的其他方面（参见：Concept：项目生命周期）。

建立一个粗略的数量级估算完成项目工作项所需要的成本。一个简单的项目成本模型可以使用团队近似的人平均成本乘以团队人数再乘以迭代的长度，来获得持续的财务影响（如，每迭代的成本）。这是第一轮的计划应该保持粗略和灵活性。该任务的目标是为了说明价值和项目的预算限制之间的对比，从而帮助利益相关人决定项目应该继续还是中止。如果需求，可以建议降低成本，如从范围中移除低价值和高成本的工作任务。

尽早为将软件（或更新）部署到生产环境制定计划策略，因为可能对 [项目工作] 造成影响。团队可能需要同操作运行支持部门一起讨论发布的时间表，以保证项目适合于整个企业部署系统。

只要可能，团队应该考虑部署多次小的发布（发布周期至少3~4个月）。频繁发布软件到生产环境是尽早从用户获得反馈以提升整个产品质量的一种好的途径。

在 项目计划 确定部署目标和发布日期。