This is another unexpected lesson from my One Year of Scrum – Lessons Learned. Originally I’d intended to write about the why the role of Product Owner is key. But I have nothing particularly enlightening to say on that subject – really it seems self evident the role of Product Owner is central to producing value for the customer. Instead when answering a question on the leandevelopment mailing list of all places I realized that choosing an iteration length is an interesting topic where I have something (useful?) to say.

Here are the factors I currently take into consideration:

• The sprint must be long enough for the developers to complete several stories, where complete means Done by your teams definition of done. Usually that would included coded, unit tested (probably via TDD), reviewed (perhaps via pair programming) and tested (preferably with automated tests).
• Long sprints tend to create allow mini-waterfall projects to appear. If you see the developers hanging on to stories until near the end of sprint – this is a waterfall smell. Heretically I think that 30 days is long sprint (still Ken Schwaber’s recommedation). Long sprints can work but it requires a disciplined team.
• Short sprints provide more feedback opportunities both for the client and process. A shorter feedback cycle can be very useful when the team is new to Scrum/Agile. I would deeply worried about a team that only had contact with its PO once/twice an iteration during the review and retrospective.
• The longest length would be you “Horizon of Stability” – the longest length of time your product owner can wait for a change to be made in the stories being worked on. If an important new issue appears on average it will take 1 1/2 iterations for the team to deliver a solution for it (if the item appears just before a planning meeting it will take one iteration, if it appears just after it will take two iterations). So your maximum iteration length depends on the patience of the PO and organization.
• Don’t worry about meetings overhead as their length is tied to the sprint length. Each meeting (except the Daily Scrum) is one hour per week of sprint.

At the extremes I’m aware of a team with an iteration length of 2 days. Their management was having a lot of trouble setting priorities and choosing among competing projects (i.e. their horizon of stability was less than a week). They had two iterations a week Mon/Tue and Thurs/Fri. Wednesday was for non-project work. Apparently it worked well enough to force the organization to solve its problems. At the other extreme I’ve read of one combined hardware software project where new chips had to be fabricated as part of every iteration – their iterations 3 months. Less than ideal – but still Agile. Unless you’re project is one of these rare examples the norm is between 1 – 4 weeks – with many teams eventually settling down at 2 weeks.

If your team is pushing for longer iterations start looking for the root cause. Are you writing your automated acceptance tests in parallel with coding the story? Do you still have a separate QA team? Are there late hand offs to other specialised groups? Have you tried bringing the specialists into your team? In the case where you still have and need specialists consider inviting team members to switch roles for a sprint. Each will gain a new appreciation for the others work.

Finally like everything else in Scrum this is a decision that should be owned by the team. Run an experiment. Agree in advance how the team will measure success and then try different iteration lengths.