Ideal Iteration Length

Posted by Vikas Hazrati on Mar 31, 2009

Sections

Process & Practices

Topics

Adopting Agile ,

Iteration ,

Agile Techniques ,

Agile in the Enterprise ,

Agile

Share |

RELATED Research

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.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   shorter is better

   by Kevin E. Schlabach

   I think the best length is two weeks... it seems to be optimal for most mature teams. My current team is one week which is a little short but we have valid reasons for it.
   
   Fighting a shorter iteration is a warning sign: agile-commentary.blogspot.com/2008/09/shorten-y...

   Reply

2. Back to top

   Re: shorter is better

   by Aslak Hellesøy

   No iterations (and estimation) can be even better - they interrupt the even flow you can achieve if you adopt Kanban.
   
   Drop the burndown and velocity and adopt Cumulative Flow Diagrams instead!

   Reply

3. Back to top

   Clinton is dead wrong on the subject of overhead

   by Mark Levison

   In Scrum (and other Agile practices) the length of the planning session scales with the length of the iteration. So if the iteration is two weeks I would expect planning to max out at four hours. In fact I will end planning meetings if they take this long. As a rule iteration planning meetings should max out at 2hrs per week of sprint. Review and retrospectives are the same.
   
   If I'm vehement its because this is a commonly repeated mistake that some will use to justify longer iterations.
   
   Also Clinton hinted at but didn't state outright - shorter iterations have the benefit of faster feedback loops. So once a problem occurs it takes less time to fix.

   Reply

4. Back to top

   this should always be reviewed in the retrospective

   by Wes Williams

   what is good today may not be good tomorrow. if the team changes or the project changes the iteration length should be reviewed. i like the principles you have listed from Mike. I do think the meeting lengths scale to the length of the iteration once the team gels.

   Reply

5. Back to top

   Re: shorter is better

   by Wes Williams

   i do like a lot of the things you get from a kanban system, like managing wip, queues, and improving cycle time. one thing that i have yet to get a good description of is in sw development the stories are not the same size so how valid is the cumulative flow in predicting when you will finish? in manufacturing you are creating the same size object every time. I have been to one of Donald Reinertsen’s workshops and I have read and heard David Anderson speak on this but it is the prediction part that seems weaker without story point estimates. Any suggested reading on this?

   Reply