Establish a cohesive team
|Revisit the resourcing for the project. Identify gaps and initiate hiring or re-allocation of resources as needed.
Discuss with the team who plays which roles, and have them agree on their responsibilities.
Estimate project size
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
Forecast project velocity and duration
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 (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.
Outline project lifecycle
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).
Establish costs and articulate value
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.