Iteration Planning

Iteration Planning Meeting

Iteration lengths typically range between 1 and 6 weeks. The team holds a planning meeting at the beginning of each iteration to break down each of the features scheduled for the iteration into specific technical tasks. Iteration planning meetings generally last from 2-4 hours - any more than that and you may be spending too much time in unnecessary planning; less time than that and you may not be doing enough planning and collaborating.

Feature Selection

Many teams set an overall goal for the iteration to help guide the selection of features. At the beginning of the meeting, the highest priority features are typically selected from the release plan. If the iteration does have an overarching goal, then some lower priority features may be selected if they better align with the goal. Prior velocity is critical to enabling the team to schedule a realistic amount of work. For example, if the team previously planned to get 40 days worth of product features, but only successfully delivered 30 days, then 30 days should be considered the current velocity for the next iteration. Past velocity estimates compared to actual numbers are useful at the iteration level, the feature level, and the task level. All of these help the team determine how much they can sign up for in the next iteration. If the iteration is overbooked, then the customer needs to select which features need to be delayed to a future iteration.

During the iteration planning meeting, the customer will discuss features with the team and attempt to answer any questions the team has. The team will break the features down into tasks. On some teams, developers will sign up for tasks and estimate them; on other teams, the development manager will assign tasks. Another popular planning method is to simply estimate the tasks as a team and queue them all up. Team members each select a task to start on and then select the next task off the top of the queue when the current one is completed. This helps to keep the focus more on team goals and less on individual achievement.

Task Planning

Tasks typically range in size from 4 hours to 2 days, with most tasks capable of being delivered within a day. Tasks larger than 2 days should generally be broken down into smaller tasks. Occasionally during task planning a feature is determined to be have been woefully underestimated in the original release plan. In this case, the team will need to work with the customer on providing a corrected estimate and determining what feature or features may need to be delayed as a result.

Iteration Adjustments

During the iteration, if there is remaining time after all features have been delivered, then the team can request that the customer identify additional feature(s) to add to the iteration. If, on the other hand, it is obvious that not all features can be delivered, then the team works with the customer to determine which features could be delayed or perhaps split in order to deliver the most value by the iteration deadline.

Warning Signs

If over a series of iterations, the team continues to push features out into the future, it is a sign that the team should pay closer attention to its prior velocity in order to minimize continuous overbooking and maximize planning accuracy. If the team keeps pushing the same features forward each iteration, it may be a signal that the team is purposely avoiding certain functionality and the root causes should be explored.

FAQ's

How do we handle dependencies between tasks?

This question comes up quite a bit. As part of iteration planning, the team should strive to minimize task dependencies as they divide features up. Specific techniques abound in Mike Cohn's excellent book User Stories Applied. Next, the team should strive to collaborate to minimize the effects of unavoidable dependencies. Agile teams typically embrace simple, loosely-coupled, adaptable designs that minimize dependencies. An excellent resource for devising and refining such architectures is Bob Martin's seminal book Agile Software Development: Principles, Patterns, and Practices. Agile teams also use techniques, tools and practices that enable them to work concurrently on interdependent subsystems and modules. Test-driven development, automated test harnesses, and mock objects help teams minimize and cope with task interdependencies. Continuous, close collaboration can be key here; co-located teams find it easier to work out dependency challenges together throughout the iteration in a just-in-time fashion.

Iterations are only so long, reducing the risk that a single lurking dependency will kill the project. PERT charts and CPM, while potentially valuable in terms of general system understanding, have a very high tendency to crumble under the stress of high-speed, iterative software development. The additional time and effort spent to build a dependency model for a two-week iteration is rarely worth the time. Automated tests and code will give you more accurate, executable feedback at least as quickly.

How much should a team member sign up for?

A team member should rarely sign up for more than the total estimate of the tasks they were able to complete in the prior iteration. If tasks are not being signed up for during iteration planning, then more emphasis is placed on making sure the team does not sign up for too much work by comparing to the prior iteration's feature and task velocity.

How do you plan iterations if team size varies?

Without the ability to rely on consistent team effort, no project approach, agile or otherwise, provides much insight. With iterative development, though, at least there is typically some history that is built up over time to use as a basis for planning. If you have delivered several iterations with a team of 10 with an average velocity of 20 ideal days or 200 hours per iteration, and you team is cut in half, then a simple calculation should lead you to plan no more than 10 ideal days for the upcoming iteration (at least initially). If key personnel have be removed, or you find you are wrong, you will find out within the next few weeks and be able to quickly adjust for future iterations.

How do you account for overhead (meetings, email, etc.)?

Teams generally do not spend much time tracking minor overhead items. Over the course of a few iterations, these interruptions are reflected in increasingly consistent (if unexpected) velocity actuals. Some teams incorporate larger interruptions and disruptions into their iteration plans explicitly, to reduce risk and increase visibility.

How do you account for bug fixing during iteration planning?

There are a couple of ways teams deal with bug fixing. One of the simplest is to include bugs as explicit input to iteration planning, prioritizing it, and estimating the tasks involved. Bugs and features are essentially equivalent units of work for planning purposes. Some teams elect to track bugs separately outside of their iteration process. This is somewhat riskier: if the bug-fixing effort varies between iterations, then the team's velocity will vary accordingly, throwing off estimates and plans. But if the bug-fixing effort is held constant, then this method can work reasonably well.

Why should iterations always be the same length?

Iterations with the same or very close lengths provide a rhythm that teams rely upon for estimating and planning. Without fixed-length iterations, it can be difficult to achieve and measure steady velocity. The discipline of cutting off production at the close of an iteration focuses everyone's minds, applying pressure to keep designs simple and resist gold-plating or scope creep. The entire organization quickly grows accustomed to a steady hum of input, planning, execution, output, and retrospection. Without this rhythm, the team is less efficient. There will occasionally be good reasons to stretch or compress specific iterations, to fit them around deadlines, major interruptions, or holidays. But these should be the exception, not the rule.

How do I account for testing and documentation time?

Testing and documentation updates should be prioritized, estimated, and planned just like any other major activity that require developer's time. They are often created as tasks under specific features, but may also be grouped as their own feature.

Should feature estimates be revised during iteration planning?

Feature estimates should only be revised during iteration planning if the original estimate is found to be way off base and the new level of effort will have a significant impact on the team's ability to complete other work.

Should task estimates be revised during an iteration?

The original task estimate should not be revised once the iteration planning has been completed. On the other hand, the estimates for future iterations should be continually revised to reflect an accurate assessment of remaining work.

Should all teams operate on the same iteration schedule?

There are advantages to having all teams working on the same iteration schedule. Rolling up iteration status across teams is only meaningful if the teams are on the same schedules. It is not helpful to roll up any numerical status across a team that is just beginning its iteration along with another that is about to finish. The disadvantage to having all teams on the same iteration schedule lies in starting up and wrapping up iterations all at the same time. If common resources (e.g. a customer or management) are shared across projects, they may appreciate a staggered iteration schedule across teams.