Iterative Planning
 I prefer to say iterative planning instead of iterative development because it places the emphasis where it belongs: You must adapt as the project unfolds by changing your plans. You can plan out an entire project into detailed iterations in advance, but that isn't Agile. You change plans based on feedback from incremental delivery of working software. The customer/product owner is part of your team so let them guide your project not just at the start but day by day. Show them the system as it is being built so they can learn more about the solution and then listen to them.
 Some Agile projects don't even have iteration ends. They remain Agile by balancing the need for stable requirements with the need to change requirements while launching working software on a regular and frequent basis. Iterations are just an easy way to demarcate when changes are accepted, when a new plan is created, and when working software is released to customers. Shorter iterations give more opportunities to plan.
 There are three Agile levels of planning. Release planning is a group of stories selected because they represent a usable set of features that can be released together. These types of plans are made by selecting the stories and deciding how many iterations are needed or by selecting a release date and seeing how much can be done by then. Release plans have no details other than a list of stories to be done by a date.
 The second level of planning is the iteration or sprint plan. This plan is a subset of the release plan stories that will be done in the very next iteration or sprint. Only one iteration plan exists at a time. With our chosen collection of important features we can now estimate the
amount of effort to implement them. The people who will do the work, namely the developers, have authority to set the estimates. The manager will set the total amount of work that the next iteration can have planned. The customer then chooses a subset of the most important features that will fit into the next iteration.
 The iteration plan will often be verified by breaking the stories into development tasks and estimating them with finer grain units. At this level use cases could also be created. This greater level of detail is permissible because iterations or sprints are kept very short.
 The third level is the daily plan. A daily plan isn't usually represented by any artifacts. At the daily scrum or stand up meeting everyone will announce their plan for the day and then act on it. Even greater detail is allowed because the plan's duration is one day and no more.
 When you slip your schedule you acknowledge how far you have come and make a new plan based on the new information. Trying to catch up only puts you further behind long term. Even if you can make it up in a short time the strain on the team puts them behind schedule next week. Keep a sustainable pace going.
 When you get ahead of schedule you make a new plan. Being ahead of schedule does occasionally happen. Keep your pace steady. Some slack time is nice, but you need to keep your team challenged or they will challenge themselves in ways you wouldn't have chosen.
 When your customer learns something important about requirements or a competitive advantage you make a new plan. Changes to requirements are welcome because we have already decided we will be making new plans
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
 The changes we get late in a project are usually the most valuable because that is when we know the most about our problem domain and solution. Consider every dollar spent on development as also being spent on learning about a better solution. The last change request is always the one you paid the most for, so use it to your advantage.
 Iterative planning is exactly what you think it is; make a plan, build some software, and then make another plan based on what you learned. Agile processes are based on the idea that planning throughout the project is just as important as having a plan. Things change, plans must either be short in duration or very sketchy in details to remain useful.
 How do we know how much we can get done in an iteration or sprint? We need to talk about creating honest plans.Honest Plans

One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
About the Author

Copyright 2009 Don Wells all rights reserved.

Most Important FirstIterative PlanningA Project HeartbeatHonest PlansTeam EmpowermentDaily CommunicationWorking Software