Development Plan

The development plan is a tool to direct your team's work and to track its progress. For this reason, an initial plan is required at the beginning of the project, when your project proposal is created. The plan is continually updated to take into account changes that occur during development. Each cycle will have a much more detailed cycle plan associated with it.

At the beginning, it is important for the team to agree on a conceptual design of the product or system to be developed. In its simplest form, the conceptual design is a list of the “pieces” which, if they existed, would make up the final system.

Once the initial conceptual design is agreed on, the team makes a list of the various things that need to be developed or delivered, and puts them in a reasonable order according to the sequence in which they will be worked on. A team may, for example, choose to complete the most risky or most fundamental parts first, so that the continuing development effort will have a strong foundation.

Although the activities within each cycle will vary significantly, the process for planning each cycle is similar. The team needs to identify:

• Required deliverables
• Project risks
• Milestones to produce deliverables and manage risks (along with effort estimates and due dates)
• Tasks that need to be completed in order to hit the milestones (along with effort estimates)

For each of the planned milestones, the team identifies the specific tasks that need to be completed (see examples in the description of the incremental development process).

This plan will be entered into FogBugz. Here is a portion of what it might look like:

Each case or subcase in the plan must have the following characteristics:

• A “boolean” completion condition – There should be no ambiguity about whether the task has been completed. (This rules out tasks like “Do some debugging on the sort method”.)
• The work described contributes directly to, or is necessary for, the success of the project. (The goal here is to focus the team on what is really important, and not to “bill time” to the project for distracting or unnecessary activities.)
• The case must be worth the time to plan and track. (Generally, a 10-minute task does not meet this criterion.)
• One member is responsible for ensure that the case is completed.

The reason for keeping track of planned and actual time (effort) is to provide a basis for future planning and plan updates. The planned completion date (week) is determined by the running total of the planned effort for each team member and the number of “on task” hours planned for each week.

Cases should be broken down into 2-5 hour chucks. This granularity allows better tracking and assessment of progress, and makes it easier to take corrective action (e.g., rebalancing workloads) if one or more team members start to fall behind the planned schedule.