BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Ideal Iteration Length

by Vikas Hazrati on Mar 31, 2009 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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...

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!

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.

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.

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?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT