In Planning Extreme Programming , Beck and Fowler, state “Any software planning technique must try to create visibility, so everyone involved in the project can really see how far along a project is. This means that you need clear milestones, ones that cannot be fudged and clearly represent progress. Milestones must also be things that everyone involved in the project, including the customer, can understand and learn to trust”.
This view is in concert with that of Andersen , who defines a milestone, not as the completion of an activity, usually an especially important one, but as a result to be achieved, a description of a condition or a state that the project should reach by a certain point in time. A milestone describes what is to be fulfilled, not the method to fulfill it. This is what makes milestone plans suitable to act as guideposts while preserving the just-in-time task planning nature of agile methods.
Figure 2 shows a typical milestone plan. As can be observed, a milestone plan is short, typically confined to a size that will allow it to be grasped at once and written using a vocabulary a project sponsor can understand. The plan comprises the sequence of states the project will go through, from its inception to its successful conclusion, and not the activities the team needs to perform to achieve those states. For example, the “UX Concept approved” milestone defines a state where the project team has presented an idea that satisfies the needs of the sponsor and he or she has acquiesced to it. This is a relevant state because once achieved, the team would have reduced the project uncertainty for itself and for the client. Notice, however, the plan does not stipulate how the team will get there. Will it build wireframe diagrams, develop high-fidelity prototypes, make a PowerPoint presentation, perform user testing, or employ focus groups? At some point, these issues will certainly have to be addressed by the team, but they have no place in a milestone plan. This focus on states is what makes the plan robust, since independent of what tasks are performed to get there, when, and by whom, the project sponsor would like to approve the design concept before it is implemented and that, is unlikely to change.
The dependencies between milestones are “Finish to Finish” relations, meaning that if “Milestone B” depends on “Milestone A”, “Milestone B” cannot be completed until “Milestone A” has been completed. Finish to Finish relations are easy to spot and provide great freedom as to when the activities leading to the realization of the milestone could start.
Milestones can be hard or soft. Hard milestones are milestones that, if not accomplished by a set date, lose all or most of their value, result in severe penalties or might induce irrecuperable delays in the project itself. For example, the date a government resolution that the system under development is supposed to address goes into effect, and the start of the holiday shopping season would be hard milestones a project might need to satisfy. The provision, by an external party, of a critical item necessary for development beyond a certain due date, would be an example of an event causing an irrecuperable delay to a project. Soft milestones, on the other hand, have completion dates that result from the planning process. They might be associated with penalties or other liabilities after a statement of work is agreed upon, but in principle they are discretionary.
|Figure 2. A typical milestone plan showing due dates, responsibilities, and milestones’ descriptions. Adapted from |