Agile Myths: Shorter iterations are stressful

One of the first steps a new agile team has to undertake is to choose their iteration length. Although I let teams choose the length they feel comfortable with, my general advice is to start with 2 weeks iterations. I believe it is better if the team make their own decisions and learn with the experience. I'm gladly surprised when a team chooses a short iteration length, but sadly that doesn't happen very frequently. Usually the main argument I've heard in favor of longer iterations is that shorter iterations are stressful and there is not enough time to finish all the work.

Opposed to this general belief, my own experience taught me that longer iterations are generally more stressful than shorter ones.
I believe the main reason behind such experience is related with the complexity in providing accurate estimations. I don't believe there is such thing as a perfect estimation and I'm convinced that high level estimates, such as story points, are more helpful to forecast than detail estimates such as ideal hours. It is very hard to convince people who come from traditional management about this idea, but as I said before, experience is the best teacher.

Let me give you some examples. Team A works with 4 weeks iterations. The first week they have a promising start and their burndown curve is aligned with the ideal trend or maybe even a bit under it. By the end of the first week the burndown curve starts moving up until it reaches the ideal trend. By the second week, it is over the ideal trend and the gap keeps expanding. Inevitably questions comes from everywhere. Why are we getting delay? The Product Owner starts getting anxious and he transmits his anxiety to the rest of the team. The next 3 weeks, the team will struggle to improve their burndown curve. Finally at the last week they decide they won't be able to finish with everything, so they just remove some scope from the iteration and try to do their best to finish with the ongoing work. With a bit of luck, they were disciplined and they started working with the most valuable stories, so they cut off from the iteration the less important stuff.

At the end of the iteration the result is clear. They've just passed a very stressing month and they are probably blaming the new methodology which was put in place. Worst thing is probably next iteration won't change much. They have work delayed from last iteration and more pressure to deliver new stuff. Besides, there are a lot of hours to fill for a whole month. It is very hard to identify and estimate all the tasks required to complete several stories, specially when they are big enough to fit in a one month iteration. Without much doubts, next iteration the same scenario will repeat: "old habits die hard".

Now let's think of a team which is working with 2 weeks iterations. Team B also starts really well and in the first week the burndown curve is a bit under the ideal trend. The second week the burndown curve have already reached the ideal trend. Although, as the team has planned small stories which can fit in a 2 week iteration and there aren't a lot of hours to fill in only two weeks, the gap between the burndown curve and the ideal trend is insignificant.

Besides, the second week is also the last week of the iteration. At this point there is not much value in looking at the burndown chart. The team has only one week to finish all the remaining work, therefore it is quite easy to recognize if everything can be finished or not. Working with a 2 weeks iteration provides the team higher visibility, reducing the probability of having to adjust the iteration scope. If there was a big mistake in the estimations, it would probably be caught very soon and the team would be able to adapt the iteration's plan without having to struggle for another 2 or 3 weeks.

Also, the team has discovered an important lesson. If they work with 1 or 2 weeks iterations, the burndown chart is not really valuable. By the time you can see some trend in the chart, the end is so close there is no need of the burndown to know how things are going to end up. Little by little they will also discover estimating tasks in ideal hours is not really necessary. High level story points give them all the information they need.

There are many other reasons to work with 1 or 2 weeks iterations. First, all the meetings, such as planning, reviews, retrospectives, are much more shorter and less exhausting. With shorter iterations there are more frequents chances to re-plan and adapt to change. This is very important, specially for teams who are starting with Agile and need to learn and try new things fast. Finally, some good practices turn to be mandatory. For example, it is not possible to deliver working software every 2-weeks without a reasonable automated test harness.

I found out frequently that when teams reject short iterations, they are just hiding other problems (e.g. communication problems between team members; lack of an automated test harness; Product Owner doesn't participate enough; too big user stories; etc.)

Shorter iterations are not stressful; it is just another Agile Myth!