Ideal iteration length in agile projects

A question that always pops up when you start an agile project, is what is the ideal iteration length for this project. As always in agile the correct answer is "it depends". But on what?

Iteration length according to the books

Many books have been written about the agile way of working. Most of these are proving rules of thumb for the iteration length. The most common mentioned iteration length varies from 1 to 4 weeks.

In iterations with a shorter length work items hardly can come to Done and there will be an overhead of agile meetings. When an iteration lasts longer than 4 weeks, it is not sprinting anymore and the feedback cycle is so long that the development team is learning too slowly from their experiences. However, non of these gives you the ultimate advise on the ideal iteration length for your project. The reason for that is very simple: it depends on  quite a number of aspects.

Aspects influencing the ideal iteration length

I have been involved in a lot of agile projects. Some of them had iteration length of 1 week, some had a 2 week iteration and in others an iteration took 4 weeks. In these project I have experienced different aspects that can influence the ideal length of an iteration.

The following aspects should be taken into account, when trying to find an ideal iteration length:

Development speed

The velocity of a team depends on the tools they use. Some tools can deliver much faster than others. A feature can take 1 hour in one tool , where the same feature in an other tool can take over more than a week.So be aware of an average implementation time of a feature.

The longer a average feature takes to develop, the longer the iteration length needs to be.

Availability product owner

In an ideal world a product owner is available every minute of a working day. The team can question him or her whenever is needed. However, in practice this won’t be the case.  The PO often is responsible for additional non project related tasks. I once did an agile project for a client. We had weekly sprint and this worked perfectly. After that a new project started for the same application, the same product owner and about the same team. However, the project owner appeared to be less available (half in stead of full time). We slightly changed the way of working, but in order to have enough time we also changed the sprint length into two weeks. This worked perfectly and we were able to show the same velocity (in two weeks) as we did before.

The less availability of the product owner the longer the iteration length needs to be.

Availability knowledge and experts

Subject matter experts and the knowledge of the desired application is essential for an agile team to develop the application. When there is a lack of either of these, the development team cannot proceed without doing a lot of assumptions. In such cases an option could be lengthening the sprint or decreasing the team size.

The longer it takes to get knowledge available, the longer iteration length needs to be.

Speed of deployment

After some features have been created, they need likely to be tested. Often these test take place in a special environment. The application has t be deployed in that environment. I have noticed that in some projects this takes seconds or minutes, but in others this may take days or even a week. If deployments take days or more a short iteration (1 week) isn’t very practical. The change that there are many untested features by the end of the sprint is so high, that this influences the team motivation negatively.

The longer the deployment time the longer the iteration length.

Team size

In general, a smell team can deliver less than an bigger team in an iteration. So, there will be little to show during the sprint review. Besides that, a bigger team will have more experiences and learning points in a certain time frame than a small team. Based on those a short iteration may cause a lot of overhead as the few team members have to prepare the review, have to implement and test the features and have to do all other agile activities.

The smaller the team the longer the iteration length.

Definition of Done

The Definition of Done contains all required deliverables for the for a work item (type). These deliverables are project specific. Sometimes just a couple of products need to be realized (e.g. just the code) and sometimes lots of products need to be created (e.g. functional and technical documentation, code, test cases, test data, test results). There should be enough time to create and validate these deliverables.

The more deliverables in the Definition of Done the longer the iteration should be.

Experiences during previous projects

When an agile team has worked together in the same setting before, they probably have already experience an ideal sprint length. This team might want to use this experience in the new project as well. However, a pit fall in this situation is not taking all other mentioned aspects into account and just go blind on the experiences from the past.

The more experiences with iteration length in similar situations the likelier a corresponding iteration length would be.

Conclusion

There is no ideal iteration length that is applicable to all projects. All above mentioned aspects, your personal experience and probably a lot more will influence your decision about the iteration length  in your project.

I would suggest that you take some time at the project start to make the correct decision for your project. If this decision appears to be unworkable, don’t hesitate to come back on it after a couple of iterations.