Wednesday, June 11, 2008

What is the ideal length of an iteration?

Many things influence the amount of time that a team should have for committing to iteration goals. Some of the factors to consider are:
  • Customer feedback
  • Experience of the team
  • The overhead of reviews and planning
  • Ability to plan the iteration
  • Balanced intensity
Customer Feedback

The length of the iteration depends on the amount of time the customers can go without seeing progress and providing input. Some core mechanics require a lot of feedback from customers, so maybe a two week iteration is best. Some teams don’t need such a rapid cycle of feedback (e.g. production teams) and so a four week iteration is fine for them.

Team Experience

The experience level of a team needs to be considered when selecting the length of an iteration. Teams that are new to agile often want to have the longest possible iterations. I generally discourage this because new teams will generally approach an iteration like a mini-waterfall project. They’ll spend a couple of days in design, a few weeks creating code and assets and then integrate, test and tune during the final few days of the iteration. Experienced teams will do a bit of each of these things daily which is a better way to work. It creates better results and allows the team to discover better value during the iteration. A team that is doing mini-waterfall will generally crunch at the end of the iteration and reach the finish line with their first attempt at the new or improved feature. This hardly gives them the best opportunity to create the best possible feature.

So I will often insist that teams new to agile stick to a two week iteration until they are used to it.

Overhead or reviews and planning

Imagine that you had an iteration that lasted one week. You’d probably spend one day that week in review and planning. That’s 20% of your time spent in meetings! The good news is that the overhead of planning and reviews doesn’t have 1:1 scale with the length of the iteration. A team should be able to get their review and planning done in a day regardless of the iteration lenght. Longer iterations might require a few hours of planning half-way through the iteration to evaluate the remaining tasks and their estimates.

Ability to plan the iteration

If the iteration goals have a lot of uncertainty and experimentation that needs to be done (in the form of spikes, or time-boxed tasks) then the iteration should be shorter than one with less risky goals. Risk implies that the solution might be significantly different from the one anticipated at the start of the iteration. It’s better change direction (or even backtrack) after two weeks than four in this case.

Balanced Intensity

As hard as it may seem to believe, sometimes four weeks is too long to give a team to work. This is especially true of teams that are new to agile. As described above, new teams will do mini-waterfall on iterations at first which leads to a pretty lax mini-design phase up front and an intense debug mini-crunch phase at the end. While the “mini-crunch” isn’t going to kill anyone it points to a loss of effectiveness over the entire iteration.

Teams will find what works best for them over time. For example the last team I was on chose a three week iteration because “it just felt right”. The two week iterations made it feel as though the review was too close to do anything too big and that a four week iteration was just too long. It depends on the team and the uncertainty level of their work.

When is an iteration too long?

As a customer, I’ll limit the iteration length to four weeks. Arguments can be raised that some technical goals (e.g. engine or pipeline development) cannot be completed in four weeks or show any progress in terms of value unless there is a longer iteration. My opinion is that this is an indication that the technical practices and how goals are created need to change. I’m highly concerned about any development progress that can’t demonstrate some value at least once a month.

Who selects the iteration length and when?

The iteration length needs to be decided between the customers and the team. If there is a disagreement, the Product Owner has the final word. If the team continues to believe there is a better length for the iteration, the PO should be open to trying that out. The length of the iteration can only be changed between iterations and shouldn’t change that often. Teams get used to the length of the iteration and so changing it is a bit of a disruption.

No comments: