Increasing Business and Technology Throughput

One of the early challenges faced by most project managers and sponsors involved in an agile/iterative project is determining how long each iteration should be.  Surprisingly there isn't a lot of guidance that can be used to determine an appropriate iteration length (although Mike Cohn has some good thoughts on the topic) with the result that most iteration cycles are determined without much context on the problem that is being solved.

Here are some quick guidelines I would offer and they're based on some underlying assumptions about an iteration and its characteristics:

Iteration Characteristics

• Time-boxed in length
• Provide a rapid feedback mechanism to encourage business input and validation
• Finish with a demonstration of working software
• Software demonstrates business value
• Software demonstrations are from an end-user perspective and should demonstrate the system using as close an approximation to the end user interface as possible.  In other words, demos shouldn't only show Fitnesse tables or unit tests (they might but be aware that your typical demo audience is more interested in seeing how the system works not its underlying mechanics).

Iteration Length Considerations

• Iterations should rarely be longer than 4 weeks which addresses the second bullet above. 
• Iterations less than 1 week or less have too much overhead associated with preparing for a demo and are too easily impacted by a single team member now being available.

Iteration Length Selection Process

• Pick an iteration length that will allow the team to demonstrate tangible units of business value.  In environments with complex business transaction lifecycles (lots of integrations, actors and business rules) this will take you closer to the 4 week period.
• Select iteration duration around the overall delivery date of the product.  A project which has a 12 month duration, 4 week iterations will provide 12 demo opportunities.  A 3 month project however would only have 3 demos probably not sufficient to get appropriate feedback from business stakeholders.
• Select an iteration length that can be supported by both clients and the development team.  Often times the development team is more than capable of supporting a two week iteration (or even a one week iteration) but without the clients/business sponsors providing requirements on a timely basis the team won't have the right input to provide a demo.  In large companies there are often many stakeholders and consequently the logistics of gathering and validating requirements will take longer, select a 3 or 4 week iteration length in these settings.
• Projects with considerable 'architecturally significant' amounts of functionality of high degrees of novelty typically require longer iteration cycles.  Enhancements to existing system can often leverage the architecture investments that have already been made resulting in shorter iterations.  However, for true 'green field' software development projects a longer iteration length should be selected.

Signs that your iteration length is incorrect:

• Development teams 'miss' demos.  This usually occurs because the teams are pushing development to the last possible moment and introduce a change that breaks the build.  Address this by ensuring a code complete point at least 8 hours before your demo, also label successful builds preferably automatically.  Develop smoke tests that allow you to determine whether build really is successful
• Team velocity shows a 'sine wave' effect.  Low velocity one iteration followed by a spike in velocity in the next iteration.  This usually means the team doesn't have enough time to 'finish' their work and can't take credit for what they've completed.

Changing your iteration length mid-stream through a project isn't something I would generally recommend (you should only do this after you have at least 3 iterations completed and have some of the signals mentioned above), consistent iterations provide a cadence and rhythm to your project and tampering with that will distort your measurement statistics and also disrupt the team.  However, if you give some thought to the purpose of your iteration you should be able to avoid this problem.