The team produces rough size estimates for each work item found in the [Project Work].

Discuss with stakeholders to determine what is realistic to develop within the constraints of the project. Use stakeholder priorities and estimates from the team to guide these discussions.

The team identifies project risks, performs a qualitative risk analysis to assess their order of magnitude, and updates the [Project Risk]. The project manager facilitates the team decision about which risks they should respond to, and which risks they should watch for.

Responses may include avoiding or mitigating risks, exploring opportunities, or increasing the probability and positive impacts of the risk. Depending on the case, work items may have to be added or removed from the [Project Work] to make sure that responses will be prioritized and handled by the team along with other project work. Because it is not feasible to plan responses for all identified risks, the team may decide to accept some of them. Keep the risks to watch in the risks list, and communicate them to stakeholders. Determine actions only if they occur.

Define the iteration length and use it to assess target velocity. The number of items to be delivered in each iteration will be set by the velocity of the team and the estimates for each item.

If the project is feature-driven, the team uses the [Project Work] and target velocity to forecast the number of iterations required to complete the project. If the project instead is date-driven, the team assesses (using the known velocity of the team) roughly how much work can be done in the given time-frame. Out-of-scope work can be considered for future releases.

The team should not spend too much time doing this planning. The project plan should document only a brief summary of project milestones and between one and three objectives for each iteration. Do not commit individual work items to the plan, because this will force too much re-planning. The goal is just to create a high-level plan outlining how the team can build the resulting application in the given set of iterations. Extra levels of detail will be achieved in other planning sessions throughout the project (for example, when planning iterations). You may need to revisit this plan later to adapt it based on what you will learn by running the iterations.

Organize iterations into a set of phases. Each phase in the project lifecycle will end with a milestone aimed at providing stakeholders with oversight and steering mechanisms to control project funding, scope, risk exposure, value provided, and other aspects of the process (see Concept: Project Lifecycle).

Develop a rough order of magnitude estimate for the costs of resources needed to complete project work items. A simplified project costing model can be applied by multiplying the approximate cost per person for the entire team by the length of an iteration to derive ongoing financial impact (that is, cost per iteration). This first round of planning should keep things very rough and flexible. The goal is just to articulate value against the budget constraints of the project, and to help stakeholders decide whether it is worth moving forward with the project or not. If necessary, propose options to decrease costs, such as removing low-value and high-cost work items from the scope .

Plan the strategy for deploying the software (and its updates) into the production environment as early as possible, because it may impact the [Project Work]. The team may need to discuss the release timeframe with the operations and support departments to ensure that the project fits into the overall corporate deployment system.

Whenever possible, the team should consider deploying small releases (release cycles of three to four months at most). Releasing software into production frequently is a good way to get early feedback from the users, in order to enhance the overall product quality.

Capture the objectives for deployment and release dates in the Project Plan.