Optimum Iteration Length

In recent months, I have had quite a few conversations with Agile teams, and one topic that comes up is how to decide on or why to adjust iteration length. When a team is adopting agile practices, they often ask “What is the best iteration length?”

Like everything else in software development, my answer is “That depends…” Depends on what? Depends on how your team “thinks”. Depends on how your team “plans”. Depends on how your team makes decisions. Depends on how your team writes or receives user stories.

This is about how iteration length affects other aspects of your teams practices.

First and foremost, your iteration length has to fit into your planning process. Every iteration, there is a planning process that is executed. The iteration must be long enough that every iteration can demonstrate measurable progress towards a goal. Your iteration is the “moment” of commitment for the team. It is also the longest amount of time the team is willing to let go before they quantify a delay or a risk. During the iteration, we may “sense” that we are behind, or falling behind, but it is the disciplined measurement, the “keeping score” that happens during iteration planning that quantifies and formalizes it. Iteration planning is where the team’s optimism encounters the rigor of process. You can’t keep saying, “we’ll be OK.” At the iteration planning meeting, we either finished what we committed or not.

This iteration length has some practical implications for the team. We prefer our stories to fit into a single iteration. Shorter iterations will cause us to break stories down into manageable chunks. That chunk size typically is the teams iteration capacity, or velocity. The amount of work that the team can complete in one iteration. Since software development cannot always be divided into an infinite number of resources, there will be times when a story cannot be divided so that it fits in a single iteration, even though it is much less than the team’s iteration capacity. We may not know this until we commit and begin the work.

When the team uses shorter iterations, especially for larger teams, to coordinate activities it can be beneficial to plan and commit tasks in iterations, in addition to stories. This “technical” planning focus allows the team to choose a smaller “moment” of commitment. After we have divided the team across stories applying the maximum number of team members per story, it is possible that one or more stories may not be able to be completed in the iteration. So we commit “tasks” instead. In this case, it is essential that every team member be able to demonstrate material progress (complete at least one task) during an iteration. So maximum task size is determined to ensure that every task is able to be completed within a single iteration. This returns us to the concept that our iteration is the longest amount of time the team is willing to let go before they quantify a delay or a risk.

How can we choose an iteration length?

Traditionally, in agile, iterations have been from 2-4 weeks in length. In my experience iteration planning takes “the team”, about 1 hour per week of iteration length – so the amount of planning overhead is pretty consistent regardless of iteration length.

Smaller team’s tend to do better with longer iterations, because they need a longer moment to generate reasonable capacity so that they can commit stories in an iteration. Larger teams may benefit from shorter iterations, especially if they are having to divide their commitment across stories and deliver concurrently.

I think that additionally, leadership and personal planning acumen supports a longer iteration. When the team has sufficient leadership to plan longer iterations effectively (i.e. with high probability of success) then longer can be easier. If over time, we realize that our planning ability is limited (i.e. we are consistently ending up in the weeds, because of unforseen obstacles – not because of short estimates or optimistic velocity projections) shorter iterations and more frequent measurement cycles may help us get traction or become more predictable. Then break down stories and tasks to get more granularity, and increase the frequency of measurable completion events (finishing a task or a story).

I have been on teams that used 1 week iterations for a long time now (since 2005) – and while we started out with concentric 4 week and 1 week iterations, ultimately we dropped the 4 week brackets, and just learned to live with the fact that some stories couldn’t be delivered in a 1 week sprint. We commit tasks more than stories, and we reflect in sprint planning when we intend to start a new story and when we intend to finish a story. Sometimes we start a sprint “under-planned” without all team members fully booked. It works well for this team.

I have tried a few unusual means of getting the team to focus on the importance of finishing, and managing work in progress. Behaviors that interfere with finishing like, multi-tasking, or having too much work in progress are planning diseases.

Behaviors that prevent clarity of sequence, like designing multiple stories in parallel but not tasking them separately, so that we can’t finish them independently, or implementing what a mock-up looks like, rather than what the story says (especially when the mockup contains elements of multiple stories for the iteration or hasn’t been refreshed after other stories were completed). These are understanding and collaboration diseases.

In my experience, changing the iteration size will not correct bad team behaviors, but smaller iteration sizes will make them more apparent. The shorter the iteration size, the more frequently we measure, and the less room there is to hide ineffective team behaviors. The shorter the iteration size the more frequently we get to have a conversation about them.