The team produces rough size estimates for each work item found in the [Project Work] (see Guideline: Agile Estimation). 

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 Risk List. 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. As 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 (see Guideline: Agile Estimation). 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) how much work can roughly 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 1-3 objectives for each iteration. Do not commit individual work items to the plan, since 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 level of detail will be achieved in other planning sessions throughout the project (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 (i.e., 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 help stakeholders to 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, since it may impact the [Project Work]. The team may need to discuss 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.