What is the right iteration length?

When picking iteration length for an agile project, there are mainly two forces that you have to balance: The rate of learning is proportional with the number of iterations, rather than the length of the project. This means that shorter iterations help you get better faster. But each iteration has some overhead with sprint reviews, retrospectives and planning. You don’t want this overhead to dominate the effort spent on the project.

For some reason, most projects I’ve seen with little experience in iterative development prefer three week iterations. Personally, I prefer two week iterations. Here is the breakdown:

  • Three week iterations: After three months, you’ve spent about 7% of your time on iteration meetings. You’ve had 4 opportunities to improve.
  • Two week iterations: After three months, you’ve spent about 10% of your time on iteration meetings. You’ve had 6 opportunities to improve.
  • One week iterations: After three months, you’ve spent about 20% of your time on iteration meetings. You’ve had 12 opportunities to improve.

Going from 93% to 90% efficiency for a 50% increase in learning seems like a good deal. Going from 90% to 80% efficiency for a 100% increase in learning, not so much.

These numbers are of course greatly simplified. You might also consider:

  • With shorter iterations, the planning time may go down. But this takes practice – it doesn’t happen automatically.
  • With very short iterations, you may not have experienced enough to learn much from the retrospective. However, if you find that you do a timeline, and most of the things people remember happened the last week, it may not be because that’s the only time something significant happened.
  • You may consider different frequencies for different ceremonies. For example, on my current project we want to have demos with our power users. But they have to travel far to visit us. So we only have a full demo every other four weeks. We plan every two weeks and have an internal review and retrospective every two weeks.

What’s the right iteration length for your project?

Creative Commons License
What is the right iteration length? by Johannes Brodwall, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 Unported License.

About Johannes Brodwall

Johannes is the director of software development for the MRM product company BrandMaster. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in English, Extreme Programming, Software Development. Bookmark the permalink.
  • Jerome Lacoste

    I also prefer 2 weeks iterations. i've used one week for very short projects (e.g. 4-8weeks), for kick starts, for small teams projects).

    I've also sometimes used short feedback sessions at the end of each week, even if one uses 2 or 3 weeks iterations (for planning). There's no reason to wait until the end of the iteration if something can be discovered and acted upon earlier.

  • gamsjo

    In general it seems that “shorter iterations are better”. Many start with 4 weeks and after a while decides to try 3 then 2. Some goes back to 3.
    I have two comments to your post:
    1. Organisations and systems are different. For some (not many!) 4 weeks seems to be the shortest practical length. In other environments the flow of new stuff coming in are small items that are easily deployed and 1 week is appropriate.
    2. I have observed the same as you; when iteration length is shortened the ceremonies are not shortened accordingly – by them self. But they should. The Scrum Master should add some pressure to this!

  • http://www.lasseziegler.com/ Lasse Ziegler

    I agree that a short iteration is usually better.

    However the greatest challenge in making iterations short is in learning how to slice your product backlog items in such a way that they are small enough (max size around 1/2 sprint for one person), they fulfill your definition of ready and can be done according to the definition of done. You should always deliver working software at the end of each sprint.

    This slicing or functionality can always be done but it will take a team some time to learn how to this and it does often require the team to change how they think.

  • Ignacio Cruz

    Johannes! I read some of your twitts, I would like to know if you can help me with an issue. I am a mexican TI student that is working on web and desktop applications with Java and .Net. I am going to be evaluated with a test of programming logic abilities to get a job. Do you have any test example that could help me? They usually present a fictional language with certain syntax and ask questions about portions of code and its correct output or syntax. I appreciate your attention and help.

  • http://www.johannesbrodwall.com/ Johannes Brodwall

    Hi, Ignacio

    Is your problem to show an example of your own work? If you need to create a program, I'd recommend trying out some coding katas. You can find good examples at http://codingdojo.org/cgi-bin/wiki.pl?KataCatal….

    If what you need is general program comprehension, I'm not sure how to best prepare for this. You could consider finding an open source project and try to run, understand and tweak the code to verify that you understand it.

    Hope this helps.

  • Nacho Cruz

    I'm specifically searching for a programming logic test that you have used to admit programmers in your enterprise or one that you had done to enter as a software designer in any enterprise. I have been doing kata, but I thought it would be better to do an actual admission exam.

    Thank you very much.

  • http://www.johannesbrodwall.com/ Johannes Brodwall

    I have at times used questions related to “Effective Java” or “Java Puzzlers” as interview questions, so books like that may be a good source of learning. I've also been at interviews where I've been asked to write code on paper or on whiteboard. Usually, this is algorithm 101 code, like binary search, quicksort etc.