Articles

Dwight D Eisenhower said, “I have always found that plans are useless, but planning is indispensable.” The Agile Manifesto tends to agree with Eisenhower and values “Responding to change over following a plan.”

Different kinds of plans play important roles at different levels. Iterations are short periods, lasting for 1 to 6 weeks, during which incremental product development takes place. Before iterations begin, there has to be a release plan. A release can come at the end of every iteration or at the end of a number of iterations.

Release planning depends on the project’s scope, schedule, and user stories. As plans go, it takes time and effort to come up with a rock-solid one! Even then, it just might not work! Do not expect release planning to be perfect. It is difficult to predict with accuracy, problems that will crop up within software development projects.

Agile recognizes the uncertain nature of software and product development and adjusts accordingly, instead of trying to manipulate scope in order to adjust time and cost. Date and Cost are the main constraints for most organizations, and these are the only constraints that can be controlled. It is better to control them, rather than compromise on the scope!

A key term that seems to pop up here is ‘velocity’, which essentially means the amount of work that can be done by a team in an iteration. If we are clear about the velocity, it becomes easy to manage the scope and produce a release plan. We can take out our product backlog, consider our velocity, and get an idea of the number of iterations needed to get the work done. When we combine these with the information on priority, vision, and critical path, we are well on our way toward making a good plan.

Now all that we need is to schedule the work from the backlog into the iterations till the fixed date. If the number of iterations exceeds the fixed date, the scope will have to be adjusted. User Stories may have to be deferred into different releases. If you are not going to compromise on any of the stories, then the schedule-based approach is not for you. When scope takes priority, velocity determines the iterations needed to finish the work. A release date can be identified.

A Release plan drives the dates and sets expectations. It will change according to the changes reflected in the project; there is a need to constantly modify and update it. This is the only way to ensure that plans are meaningful, accurate, valuable, and indispensable.

Dwight D Eisenhower said, “I have always found that plans are useless, but planning is indispensable.” The Agile Manifesto tends to agree with Eisenhower and values “Responding to change over following a plan.”

Different kinds of plans play important roles at different levels. Iterations are short periods, lasting for 1 to 6 weeks, during which incremental product development takes place. Before iterations begin, there has to be a release plan. A release can come at the end of every iteration or at the end of a number of iterations.

Release planning depends on the project’s scope, schedule, and user stories. As plans go, it takes time and effort to come up with a rock-solid one! Even then, it just might not work! Do not expect release planning to be perfect. It is difficult to predict with accuracy, problems that will crop up within software development projects.

Agile recognizes the uncertain nature of software and product development and adjusts accordingly, instead of trying to manipulate scope in order to adjust time and cost. Date and Cost are the main constraints for most organizations, and these are the only constraints that can be controlled. It is better to control them, rather than compromise on the scope!

A key term that seems to pop up here is ‘velocity’, which essentially means the amount of work that can be done by a team in an iteration. If we are clear about the velocity, it becomes easy to manage the scope and produce a release plan. We can take out our product backlog, consider our velocity, and get an idea of the number of iterations needed to get the work done. When we combine these with the information on priority, vision, and critical path, we are well on our way toward making a good plan.

Now all that we need is to schedule the work from the backlog into the iterations till the fixed date. If the number of iterations exceeds the fixed date, the scope will have to be adjusted. User Stories may have to be deferred into different releases. If you are not going to compromise on any of the stories, then the schedule-based approach is not for you. When scope takes priority, velocity determines the iterations needed to finish the work. A release date can be identified.

A Release plan drives the dates and sets expectations. It will change according to the changes reflected in the project; there is a need to constantly modify and update it. This is the only way to ensure that plans are meaningful, accurate, valuable, and indispensable.