Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Making a Decision
One of the main goals in selecting an iteration length is finding one that encourages everyone to work at a consistent pace throughout the iteration. If the iteration is too long, there’s a natural tendency to relax a bit at the start, which leads to panic and longer hours at the end of the iteration. Strive to find an iteration duration that smoothes out these variations.
Having experimented with a variety of iteration lengths, my general preference is two weeks. One-week iterations (or anything shorter) can be very hectic and stressful. The next deadline is never more than four days away. Extremely short iterations leave no time for recovery if a team member is out sick or if anything goes wrong. Unless a project already has fully automated tests for all parts of the system, I don’t often recommend starting with one-week iterations.
A four-week iteration, on the other hand, begins to feel like an eternity after having worked in one- and two-week iterations. With four-week iterations, I find that the team often has time to investigate and pursue more creative solutions than they may have time for with shorter iterations. An experienced agile team working on a highly exploratory phase of a project may benefit from a four-week iteration. However, four-week iterations have a feeling of very distinct beginnings, middles, and ends. I don’t like how different the relaxed beginning feels from the more frantic end.
I find two-week iterations to be ideal. The overhead for planning and testing is much more manageable when amortized across two weeks. The first week of a two-week iteration may feel different from the second week, but the difference is not as dramatic as on a four-week iteration. Additionally, with sufficient practice most organizations can learn to set and not change priorities for two weeks, whereas doing so for four weeks can be very difficult.
As a final bit of advice, once you determine the appropriate iteration length, stick with it. Teams benefit greatly from having a rhythm to their projects. Any regular iteration length can provide this rhythm. This doesn’t mean that you can’t experiment with a different length, but avoid bouncing among different lengths without good reason.
Mike Cohn is the author of Agile Estimating and Planning, on which this article is based.