Software project planning is an activity that combines estimation with risk analysis, scheduling and other decision-making activities. Its purpose is to determine a likely course of events and the consequences of the inevitable changes. A project plan establishes visibility of the units of work that comprise a software project by:

1. Communicating scope and resources to enable effective coordination between stakeholders and team members
2. Defining risks and identifying mitigation and aversion techniques
3. Delineating cost and timetable
4. Identifying a priority order of work to ensure that the most important units are developed first

It is tempting to plan the whole software project in detail at the start, predicting its route far into the future. But in reality, the structure of such a project plan will degrade with time as unforeseen events occur and circumstances change. A project plan needs to be flexible and ready to adapt. It is more efficient to plan with a decreasing granularity - create detailed project plans that itemize the tasks for the next few weeks and outline project plans that identify the requirements for the next few months. Beyond this, say after a year, any plans should be extremely coarse. This means investment is made only is the immediate tasks and milestones. Within the detailed plan it is difficult to change because of momentum and commitment, but beyond the immediate few weeks the remainder of the plan is flexible and can be changed easily.

An effective software project management strategy that complements rapid application development (RAD) and the use of agile methods employs techniques known as release planning and iteration planning, where a release is made up of a defined number of iterations. Planning tools that facilitate such an approach are V1:XP and XPlanner.

Release planning

The purpose of release planning is to synchronize the project with the business by allocating requirements to releases. It is collaboration between the customer, the business team and the technical team. The customer and business team essentially drive by performing the following duties:

• Define the requirements
• Assign a business value to each requirement
• Decide the requirements to build in a particular release, ordered by descending business value

The technical team help navigate by performing the following duties:

• Estimate how long it will take to build each requirement, based on historical metrics
• Identify and advise of technical risks
• Measure progress to provide a 'feedback loop' that facilitates adjustments to the plan

The technical team need to know what requirements are in the current iteration; it is also useful for them to know what requirements are in the next iteration. However, the business team need to know what the contents of the current release are, and it is useful for them to have an idea of the contents of the next release. The resultant plan is by no means stable. It will be revised frequently to accommodate business changes such as revised priorities, re-assessed business values and specification changes, and technical changes that may impact the speed of development. How far ahead to plan is really a trade-off between the volatility of the project plan and the effort required to maintain it, and the value of the project plan itself.

Iteration planning

The purpose of iteration planning is to load the development team with work organized to deliver the requirements selected for the iteration.

Collaborating with the customer and/or the business team to fully understand the requirements, the development team will break each requirement down into a list of tasks and estimate them. Each developer will then volunteer for a task, assuming responsibility for its successful completion. When completed they will volunteer for the next available tasks. The work associated with the tasks identified at this level can be estimated more accurately than descriptive requirements, and they are sufficiently small enough to be easy to track.

The tasks and estimates are scheduled in the iteration plan. The plan belongs to the development team; it is their responsibility to decide how to do things and in what order. Tracking data is also entered into the iteration plan and the metrics derived are used to steer the project.