After all the cards are written and estimated, it is time for the customers to pick the first iteration, for which they need a velocity and a length of time. Usually after a creatively exhausting meeting, both are chosen arbitrarily, or with minimal stimulus.

I have been on projects with one week iterations and one month iterations, all with varied success. The formula for the length seems to have different inputs for success, involving customer participation, speed of changing requirements, and physical location.

All of these factors are prescriptive, attempting to plan the needs of the team based upon known constraints, something software craftsman are very familiar with. The most successful iteration length for the teams I have been on is one week, regardless of other constraints.

Thanks to an excerpt from Donald Norman’s new book, Emotional Design, I think I understand why environmental constraints do not affect iterations ideal length:

…being happy broadens the thought process and facilitates creative thinking. [Alice] Isen discovered that when people were asked to solve difficult problems, ones that required unusual “out of the box” thinking, they did much better when they had just been given a gift—not much of a gift, but just enough to make them feel good.

One week iterations are the perfect length for all of these emotions to be useful. At the begging of an iteration is when you solve the tougher problems, not worried about a deadline. Your creativity can know no boundaries, everything is possible.

A refactoring spanning a few days seems manageable, a large story looks like it can get done without sweating. Really, as a developer, the day after the iteration meeting is often the happiest day you have, especially if you hit your velocity.

You are ready to spread your wings and impress the customers at the next iteration meeting. The book goes on to say:

…when people are anxious they tend to narrow their thought process, concentrating upon aspects directly relevant to a problem.

As the iteration progresses, you start to feel the meeting. You think: “I can’t get all of my ideas done by the meeting” and “I can’t show up empty handed”. This is when some of the more grandiose ideas get cut and you start to concentrate more on the acceptance of stories.

As it gets closer to iteration day, you become more granular, focusing all of your energy on acceptance of stories. This blocks out the bigger designs and system solutions from your frame of reference.

Even within a solution, I have banged my head against a solution for hours, without thinking to sidestep it. It is always harder to think of an alternative solution to a problem on the last day of an iteration than on the first.

This is good for iterations, you cycle through all of these emotions, not staying on any of them too long. Too many days at the beginning of an iteration leaves developers wide eyed about refactorings or experiments. Sprinting at the end of an iteration for too long leaves a team stressed and under productive.

However, all those emotions in small doses, on a continuum is good for the project and good for the developer. You get to flex your developer muscles and try out something cool, but by the end of the iteration, you are focussed on finishing the features the customer needs.