Iteration Planning
Iterative Development is a key element to adding agility to the development process. The development schedule for a release should be divided into iterations of about 1-3 weeks in length. This length is kept constant, despite pressures to increase length in order to fit “one more feature” in.
The result of this constant iteration size is a rhythm that the process takes on. It provides predictability for the Product Owner, Managers, Developers and Testers alike. The use of shorter iterations also accommodates changes in a system’s requirements. Unless a change represents a complete paradigm shift, it is always scheduled for a later iteration based on its priority from the Product Owner’s point of view. By having shorter iterations, such a change is at worst a couple of weeks away from being implemented.
The programming tasks shouldn’t be scheduled in advance. Instead, these are fleshed out during the Iteration Planning Meeting at the beginning of each iteration.
Iteration Planning Meeting
An Iteration Planning Meeting is called at the beginning of each iteration to produce that iteration’s plan of programming tasks. User stories are chosen for this iteration by the Product Owner from the Release Plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected.
The number and size of Stories selected depends on how much work was completed in the previous iteration. This concept is known as Yesterday´s Weather. This is a risk management activity that addresses the tendency to over-book an iteration, and accommodates estimates that were perhaps too optimistic. The actual value of the Stories completed in the previous iteration is referred to as the Project Velocity.
The selected Stories are then broken down by the developers into the programming tasks required to implement the Stories. These tasks are the detailed plan for the iteration, and should be 1 to 3 ideal programming days in duration. Ideal programming days are how long it would take to complete the task if there were no distractions. Tasks which are shorter than 1 day can be grouped together. Tasks which are longer than 3 days should be broken down even further.
Note that the estimates provided include the time for writing Tests and to perform Refactoring. These practices are critical to reducing the technical debt within the code, and allowing the team to continue to progress towards a completed system.
You should also resist the temptation to adjust estimates in order to “fit” more stories into an iteration. What often happens is that the initial estimate for a story won’t match the combined estimates of the tasks required to implement it. That’s actually a good safety net to catch stories that were larger than first thought, and the general rule of thumb is to change the story’s estimate to match the tasks. That may result in more hours, days or points than specified by Yesterday´s Weather. If that’s the case, the Iteration Plan must be adjusted by removing stories (and possibly adding smaller ones) in order to fall within the bounds of the previous iteration´s actual amount of work completed.
If the team happens to complete all of an iteration´s work before the end of the iteration, they approach the Product Owner to ask for more work that will fit the remaining time. This often happens when a previous iteration had a particularly low amount of completed work, possibly due to illness, vacation, etc. It is generally better to use the lower estimate based on Yesterday´s Weather and add Stories, than it is to attempt to account for the differences and try to fit more work in the iteration.
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus