How Long Should Our Iterations Be?

Scrum originally proposed iterations (called sprints) of 30 days. Extreme Programming says 1 to 3 weeks. Lean questions whether to even have an iteration (i.e., why not a continuous flow of stories). Where should you start?

I generally recommend that projects start with two week iterations. Once you get a feel for things, you can adjust to what is appropriate for your environment.

Often I get a response of "Gee, that's awfully quick; maybe we should start at three weeks). Usually there are two reasons people want to shift to a longer iteration. First, they find it hard to believe that you can actually accomplish anything in two weeks. Second, they think that the overhead of the iteration will become too high with a smaller iteration.

You really can get something developed, tested and documented within two weeks. The biggest challenge is to break things up into small enough increments. This is a mindset change (incremental rather than all or none). Each story should be on the order of two to five days. If it is too big, break it down into vertical chunks. Each chunk should be leveragable as is and should provide some customer value (however small). For example, editing something could be reduced to just viewing it. This could be further reduced to just viewing some of the attributes.

Another challenge might be your organization. Your goal is to get the team (or each team if there are many) so that they can accomplish the stories within the team (might be virtual). The more they have to go outside the team or work with other teams, the harder it is going to be to get things to fit in the iteration. See this previous blog entry for more on this topic.

What about the overhead argument? Well, there is some overhead to each agile meeting (getting it started, getting it flowing, etc.). But generally speaking, if your iterations become longer, each meeting will become proportionally longer since the scope is bigger. A larger concern might be your regression testing. Until this is automated, it will add overhead to your iterations. One interim solution might be to do much of the manual regression testing in the subsequent iteration. The downside of this approach is that it delays feedback. But as you get this more and more automated, the delay becomes shorter and you can eventually pull it into the iteration (the already automated aspects can be pulled in from the start).

The longer the iteration, the harder it becomes to get your head around the work in the iteration. In particular, small increments make it easier to get into details (since there are fewer details). This includes details on requirements, testing, documentation, etc. Another possible issue is that you could find yourself getting into the mindset where the iteration is long enough to accomplish anything (i.e., you start getting less concerned with whether things fit). You'll find things going slower at the beginning of the iteration (plenty of time) and picking up dramatically later in the iteration (no time). Finally, you have less points at which to steer the "boat". Fewer cycles to adapt and learn as a team. More risk if you go down a bad path. Less visibility into progress.

The smaller the iteration, the more intense it becomes. I know several teams that are doing one week iterations and are happy with it. You have to break things into even smaller chunks and you run the risk that the iteration contents aren't significant enough or that you're giving too much feedback. If you can get to the point that every story when checked in is releasable, then you could consider going iterationless. But, I wouldn't start there unless your work is so unpredictable that it can't be planned (ex., support).

For more on this topic / another point of view, check out Mike Cohn's blog entry on the subject.