Roadmap: How to Adopt the Two-Level Project Planning Practice |  |
This roadmap describes how to adopt the two-level project planning practice. It helps an organization get prepared for creating a coarse-grained plan for the project, which in turn is used tol guide the fine-grained plans and activities that happen throughout the project.
Main Description
### Getting started Two-level project planning is concerned with creating a strategic project plan (where the internal and external releases of the project are identified), and tactical iteration plans for individual iterations within releases. It aims at creating the right level of granularity for each purpose, so that the investment in planning is held to a minimum. Begin by understanding the high-level features that the system is expected to possess. These are the system's main themes or services, and they are typically described or listed in a vision document. They serve to set goals and expectations, both internally and externally, and they guide and constrain the iteration planning. The project plan is coarser-grained than iteration plans. As [LEF07] notes, a system can be described with a list of 25-50 features, calibrated to the relative complexity of that system. Iteration plans, on the other hand, are described in terms of individual user stories, use cases and scenarios, or other work items that will be developed in each iteration. As early in the project as possible, ideally as part of the kick-off of a new project, hold a planning session (with the whole team and the stakeholders of the system) during which the initial project plan is established. Update the project plan as often as necessary to reflect changing business priorities and needs. Iteration plans help to estimate and track individual iterations. For each iteration, its plan is created just-in-time, based on the currently highest prioritized work items in the product backlog. ### Common pitfalls One of the biggest challenges with agile planning is to resist pressure from upper management if they require to see complete plans up-front in the project. This is best avoided by involving them in the planning process, and by demonstrating the value of empirical planning by making the process transparent and open (to the organization and the project's stakeholders) so that they can easily follow the progress of the project. It can be difficult to find the right level of granularity for the features of a given system. With too many features, the planning process becomes tedious and error-prone, and will work counter to the intent.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. OpenUP Copyright