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

Discussions are held with the stakeholders to determine what is realistic to develop within the constraints of the project.  Stakeholder priorities and estimates from the team are used to guide these discussions.

If the project is feature-driven, the team looks at how many people they would need to complete these work items, which gives them a high level understanding of project duration, staffing profile, and scope. If the project instead is date-driven, the team assesses how much work can roughly be done in the time-frame given and using the available team. Out-of-scope work can be considered in future releases.

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 risks identified, the team can decide to accept some of them. Risks to watch will be communicated to stakeholders and remain on the Risk List.  Actions will be determined only if they occur.

[*** This is a new step.  It is added because the 2nd paragraph of the prior 'Outline project lifecycle' step needs to be contributed as a follow-on step from risk-value lifecycle.  The 1st and 3rd paragraphs of the original Outline project lifecycle step are appropraite here.   NOTE:  This content introduces a dependency of this practice on Iterative Development.  ***]

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. The team uses the Work Items List to outline what features to implement in what iteration, putting top priority work items first, including planned responses to the higher risks or opportunities.

You don't need to spend too much time in 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 (see Task: Plan Iteration). You may need to revisit this plan later to adapt it based on what you will learn by running the iterations (see Artifact: Iteration Plan from previous 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's worth moving forward with the project or not. If necessary propose options to decrease costs, such as removing from the scope low value and high cost work items.

[*** Reword this to indicate that Project Work may be impacted, but don't show that being done here...it is the task of iterative development (plan and manage iteration) to do that. ***]

Plan the strategy for deploying the software (and its updates) into the production environment. Discuss release timeframe with the operations and support departments to ensure that your project fits into your overall corporate deployment system. If you are replacing an existing system, decide whether you will run the new system in parallel with it or you will perform a cutover. You may also have to negotiate with the owners of the systems that the new system has dependencies on. Update the [Project Work] with additional work that may be needed for deployment. Add significant deployment risks to the Risk List and, if necessary, make adjustments to the Project Plan.