One of the frequent questions in Agile adoption is related to the ideal iteration length. Teams usually gravitate between iteration lengths ranging from a week to two months. Choosing the right iteration length is an important decision and the success of Agile adoption depends a lot on the right iteration size. A few Agilists share their view on the factors which should be considered for making the right decision.
Clinton Keith suggested that teams new to the Agile process should chose smaller iterations because it helps them learn and validate faster. According to him,
Teams that are new to agile often want to have the longest possible iterations. I generally discourage this because new teams will generally approach an iteration like a mini-waterfall project. They’ll spend a couple of days in design, a few weeks creating code and assets and then integrate, test and tune during the final few days of the iteration. Experienced teams will do a bit of each of these things daily which is a better way to work.
According to Clinton, the following factors should be considered for making a decision on the iteration length
- Customer feedback – The minimum amount of time in which a customer can provide feedback on the progress made.
- Experience of the team – If the team has less experience with Agile, the iteration length should be short enough so that the team learns faster.
- The overhead of reviews and planning – Generally a day is spent in reviews and planning which should be accounted for.
- Ability to plan the iteration – If the iteration goals have a lot of uncertainty then the length should be shorter.
- Balanced intensity – The intensity of work during the iteration should be consistent.
Vikrama Dhiman suggested similar factors for deciding on the iteration length. He also suggested that the iteration length would also depend on the capability of the product owner to divide the functionality into smaller stories. Smaller stories can be easily completed and tested within a small iteration cycle. He added the following benefits of smaller iterations,
- Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
- Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
- Shorter sprints or iterations force continuous evaluation regularly and quickly.
- Shorter sprints or iterations also allows the team to establish an empirical velocity very quickly.
Mike Cohn suggested the following attributes for deciding the right iteration length
- Amount of uncertainty – Higher the uncertainty, shorter should be the iteration length to tackle the uncertain scenario.
- How Long Priorities Can Remain Unchanged – If the priorities for the stories are changing within an iteration then it is a fair indication that the iteration length needs to be shortened.
- The Overhead of Iterating – If the project needs a ‘manual’ regression suite to be executed at the end of each iteration then shorter iterations could be more expensive.
- How Soon a Feeling of Urgency Is Established – If the iteration lengths are too long then the team tends to become complacent through the early phase of the iteration and gets into a crunch mode towards the end. The key is to decide on a length which encourages the team to work at a consistent pace.
Mike suggested that as per his experience with different teams, two week iterations seem ideal. The overhead of planning and testing is manageable and the teams are able to sink into a consistent rhythm. He concluded with the following advice for Agile teams
Once you determine the appropriate iteration length, stick with it. Teams benefit greatly from having a rhythm to their projects. Any regular iteration length can provide this rhythm. This doesn’t mean that you can’t experiment with a different length, but avoid bouncing among different lengths without good reason.