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?

Comments:

Johannes Brodwall - Jun 17, 2010

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.

[Nacho Cruz] - Jun 16, 2010

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.

Johannes Brodwall - Jun 16, 2010

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.

[Ignacio Cruz] - Jun 16, 2010

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.

[Jerome Lacoste] - Feb 26, 2010

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.

Lasse Ziegler - Mar 3, 2010

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.

[gamsjo] - Mar 1, 2010

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!