My first experience with any process that was similar to an Agile approach was in a startup ten years ago. We did 3-day-long iterations on a software project with a three person development team. That experience, followed by its antithesis, shaped the rest of my life. And yet, short iterations aren’t always the best way to go.

A short iteration length for a given type of work will depend on the horizon of predictability for that work. In software development, anything five working days or less could be considered short. In daily newspaper publishing, fifteen minutes or less could be considered short. As a rule of thumb, “short” simply means that it is possible to fit two or more iterations in the length of the horizon of predictability.

Pros of Short Iterations

– deliver work fast: the first potentially shippable features are available after only a very small amount of time
– people keep focused on the goal(s) for the iteration; there is no chance to get distracted
– very tight learning feedback loop allows for quick discovery of optimal solutions

Cons of Short Iterations

– intensity of work can lead to burnout
– strategic thinking can be hard to fit into the “schedule”
– overhead tasks that must be done every iteration take a larger proportion of the time in the iteration
– waiting for resources or people outside of the team can make it more likely for work to span iterations

Guidelines: Choosing Iteration Length

1. Start by understanding the horizon of predictability in your environment. This is the maximum length for your iterations. In most IT organizations, this is somewhere around four weeks, whereas in web environments, it is usually much shorter.
2. Consider your constraints for delivering potentially shippable work units. Also consider the team size and the communication overhead that results. These two factors can guide you to determine a minimum iteration length. Identifiable overhead should not account for more than 25% of your time.
3. At the start of a work effort with a team new to Agile Work, consider erring towards shorter iterations. Shorter iterations can shock people into discarding bad habits by changing people’s mental model of how to work effectively. Teams with successful agile experience may consider longer iterations.
4. Consider your ability to automate overhead work tasks and testing tasks. If you can develop a highly automated environment, shorter iterations are possible. If on the other hand, manual efforts will be required (no pun intended), consider a longer iteration length.
5. Consider the overall amount of schedule/funding. For a team to learn the domain and stabilize their velocity, consider trying to fit eight or more iterations into the overall schedule. The first three our four iterations include a lot of learning about the team, the process and the domain.

Some people recommend other methods of choosing the length of your iterations: How Long is a Timebox.

(UPDATE) Here is a more recent article I wrote called “21 Tips on Choosing a Sprint Length“.

What We Did Way Back When…

The three day iteration length was largely determined by how frequently the sales folks could bring in potential customers for a demo. Every time we demoed, we were using working software. We would do a fairly complete walkthrough of the software and gather feedback. We would balance the feedback with outstanding features and make a call about what to add/change over the course of the next iteration. This constant involvement of customers and the requirement to have always-working software set my expectations for software development in a way that my experience up to that point had not even hinted at. When I went to my next job (which was at Sun Microsystems), I was appalled by the long cycle time to produce working software and the almost complete lack of customer involvement in the process. I vowed never to work that way again…

… and became a consultant and an agilist 🙂

Affiliated Promotions: