We are currently working out how long our iterations should be*. I have two questions:
What factors should be considered in determining the iteration (e.g. "story/feature complexity", number of team members, and so on)?
What resources exist with guidelines for iteration planning (books, magazine articles, URLs)?
*We == my boss.
Short answers for each:
Customer pariticipation's frequency would be a major factor to my mind as they may want to see a demo every month or quarter, etc. I'm not sure what some other big ones are though.
Selecting the Right Iteration Length for Your Software Development Process from InformIT may be useful in some ways for other ideas.
Iteration length is not that important - what's more important is that iterations all have the same duration, so that the amount of complete work can be compared.
That being said, iterations should be long enough so that the Team can complete at least 5-8 stories.
For what is worth, the "official" Scrum Sprint is 30 days long.
As far as URL are concerned, refer to Ideal Iteration Length and XP iteration planning.
There's no hard and firm answer here, as agile is more of an umbrella term that covers many specific methodologies.
Personally, I like to keep my iterations as small as the solution could possibly allow. What this means, is that for every iteration, I go through with the users:
This is hardest to solve on the first few iterations. Really focus on delivering the smallest piece of functionality possible, even if it's barely useful.
For this reason, I don't like defining fixed iteration lengths, although a maximum of 3-4 weeks is usually ideal. Your first iteration may be as short as a few days to get a functional skeleton of a program up. Later iterations may be several weeks long.
Resist the temptation to build a "framework" with your first few iterations. Build the minimum possible solution, and don't try to anticipate what problems you might need to solve in the future. Add abstractions and frameworks to solve pain, not to anticipate it.
I'm also not a huge fan of the approach of scheduling multiple stories, requirements, features, or what have you into one iteration. Doing 8 differing things on a project is a good way to reduce developer cohesion and have things get lost in the shuffle. This usually isn't a popular opinion with the business side, however.
Finally, one thing that has been very useful with customers in the past is to divorce the concept of iterations from public releases. The fact that an iteration is complete doesn't necessarily mean it's ready for the public yet. Set up a beta environment for early adopters and user representatives to play around with, and package multiple iterations into monthly / quarterly / yearly / whatever releases for your main project. Tying iterations to your release cycle puts way too much business and user pressure on your development methodology.
An iteration should not be typically more than 4 weeks and at the end of it, you should be able to show a demo to the customer for a subset of features demanded by him. Typically all stake holders can sit together and decide on the features.
This link may be of some help: http://www.versionone.com/Resources/IterationPlanning.asp
Novice Rule: Make your iterations long enough to complete 4-10 stories, but look for ways to reduce the size of your stories. http://www.jbrains.ca/permalink/5
Competent Rule: Start with any iteration length that makes you comfortable, but stay aware of your key feedback cycles. If you find that a key feedback cycle is too long (and you'll know it when it happens), then try cutting that feedback cycle in half until you get comfortable with that. Then cut it in half again until you get comfortable with that. Keep cutting it in half until you get the feedback you need when you need it.
Good luck.