Chapter 15. Selecting an Iteration Length
“Everything is vague to a degree you do not realize till you have tried to make it precise.”
—Bertrand Russell
The majority of the agile processes, and teams using them, have settled on iteration lengths of two to four weeks. Some teams use longer iterations but two to four weeks is an accepted standard for most teams. There’s no one magic iteration duration that is right for all teams under all circumstances. The right length for a team on one project may not be the right length for that same team on a different project.
Factors in Selecting an Iteration Length
Your selection of iteration length should be guided by the following factors:
• The length of the release being worked on
• The amount of uncertainty
• The ease of getting feedback
• How long priorities can remain unchanged
• Willingness to go without outside feedback
• The overhead of iterating
• How soon a feeling of urgency is established
There is no predetermined relative importance to these factors. The importance of each is entirely dependent upon the context of the project.
The Overall Length of the Release
Short projects benefit from short iterations. The length of a project’s iterations determines
• How often the software can be shown (in potentially shippable form) to users and customers. Yes, of course, the software can be shown in miditeration form to these audiences, but the software usually is of potentially shippable quality only at the end of an iteration.
• How often progress can be measured. It’s possible to get a sense of a team’s rate of progress during an iteration, but only at the end of an iteration can we truly measure how much work has been truly completed.
• How often the product owner and team can refine their course, because priorities and plans are adjusted between iterations.
If a team is working toward a release that is perhaps only three months away, one-month iterations will give them only two opportunities to gather end-of-iteration feedback, measure progress, and adjust course. In most cases, this will be insufficient.
My general rule of thumb is that any project will benefit from having at least four or five such opportunities. This means that if the overall project duration will be four or more months, it might be worth considering monthly or four-week iterations. If the overall release will, however, be shorter, the project will benefit from proportionally shorter iterations.
The Amount of Uncertainty
Uncertainty comes in multiple forms. There is often uncertainty about exactly what the customer or users need, what the velocity of the team will be, and about technical aspects of the project. The more uncertainty of any type there is, the shorter the iterations should be. When there is a great deal of uncertainty about the work to be done or the product to be built, short iterations allow more frequent opportunities for the team to measure its progress through its velocity and more opportunities to gather feedback from stakeholders, customers, and users.
The Ease of Getting Feedback
Iteration length should be chosen to maximize the amount, frequency, and timeliness of feedback to the whole team. Depending on the environment, this may mean longer or shorter iterations. In some organizations, it is extremely easy to get informal feedback from internal stakeholders or users throughout an iteration but extremely difficult to get these same individuals to participate in a scheduled end-of-iteration review meeting. Other organizations have the opposite problem; it is difficult to get feedback on a day-to-day basis, but stakeholders, users, and others will attend a scheduled, formal review meeting (especially if food is provided).
Choose your iteration length to maximize the value of the feedback that can be received from those inside and outside the organization.
How Long Priorities Can Remain Unchanged
Once a development team commits to completing a specific set of features in an iteration, it is important that they not be redirected from that goal. It is, therefore, important that the product owner not change priorities during the iteration and that she help protect the team from others who may attempt to change priorities. Because of this, the length of time that priorities can go unchanged is a factor in selecting the iteration length.
A key consideration is how long it takes a good new idea to be turned into working software. Consider the case of a team using four-week iterations. If we assume that new ideas are equally likely to occur any time during an iteration, on average, a new idea can be said to occur in the middle of the iteration. That new idea will be prioritized into the next iteration, which starts in two weeks. It will take another four weeks (a full iteration) before the new idea shows up as potentially shippable, working software. This is shown in Figure 15.1. The key point to remember from this example is that the time from new idea to working software will be an average of 1½ times the length of the team’s iterations.
Figure 15.1. It takes an average of 1½ iterations to go from idea to software.
As described in Chapter 14, “Iteration Planning,” a team with maintenance or support duties concurrent with their new development work will hold some amount of time in reserve for those support and maintenance activities. Figure 15.1 is really illustrating the situation in which someone approaches the team with an idea that does not fit as part of their maintenance or support reserve.
Willingness to Go without Outside Feedback
Even with a well-intentioned and highly communicative team, it is possible that the results of an iteration could be found worthless when shown to the broader organization or external users at the conclusion of the iteration. This may happen if the developers misunderstand the product owner (and don’t communicate often enough during the iteration). It could also happen if the product owner misunderstands the needs of the market or users. The loss is almost never complete as long as we learn something from it. However, the less often a team receives outside feedback, the more likely we are to go astray and the greater the loss will be when that happens.
The Overhead of Iterating
There are costs associated with each iteration. For example, each iteration must be fully regression tested. If this is costly (usually in terms of time), the team may prefer longer, four-week iterations. Naturally, one of the goals of a successful agile team is to reduce (or nearly eliminate) the overhead associated with each iteration. But especially during a team’s early iterations, this cost can be significant and will influence the decision about the best iteration length.
How Soon a Feeling of Urgency Is Established
Colleague Niels Malotaux (2004) points out that “As long as the end date of a project is far in the future, we don’t feel any pressure and work leisurely. When the pressure of the finish date becomes tangible, we start working harder.” Even with four-week iterations the end date is never very far in the future. But it is sufficiently far away that many teams will feel tangibly less stress during their first week than during the fourth and final week of an iteration.
The solution to this, of course, is to select an iteration length that evens out the pressure the team feels. The point is not to put the team under more pressure (“You will deliver today!”). Rather, it is to take the total amount of stress they’d normally feel and distribute it more evenly across a suitably long iteration.
Stick with It to Achieve a Steady Rhythm
Whatever duration you choose, you are better off choosing a duration and sticking with it rather than changing it frequently. Teams fall into a natural rhythm when using an unchanging iteration duration. When I started doing agile development using an early variation of Scrum (Takeuchi and Nonaka 1986; DeGrace and Stahl 1990), my teams used to select the duration of each iteration based on the amount of work we were bringing into that iteration. A two-week iteration could be followed by a six-week iteration, which could be followed by a four-week iteration, and so on. Through experimentation on many projects, I have since learned that teams are far better off sizing the work to the length of the iteration (rather than sizing the iteration to the work).
A regular iteration rhythm acts like a heartbeat for the project. Colleague Simon Baker, an agile coach with think-box ltd., describes it by saying that “Like a heart beats with a regularity that keeps the body going, a fixed iteration duration provides a constant which helps establish a development (and delivery) rhythm. Rhythm in my experience is a significant factor that helps achieve a sustained pace” (2004).
Making a Decision
One of the main goals in selecting an iteration length is finding one that encourages everyone to work at a consistent pace throughout the iteration. If the duration is too long, there is a natural tendency to relax a bit at the start of the iteration, which leads to panic and longer hours at the end of the iteration. Strive to find an iteration duration that smooths out these variations.
Having experimented with a variety of iteration lengths, my general preference is two weeks. One-week iterations (or anything shorter) can be very hectic and stressful. The next deadline is never more than four days away. Extremely short iterations leave no time for recovery if a team member is out sick or if anything goes wrong. Unless a project already has fully automated tests for all parts of the system, I do not often recommend starting with one-week iterations.
A four-week iteration, on the other hand, begins to feel like an eternity after having worked in one- and two-week iterations. With four-week iterations, I find that the team often has time to investigate and pursue more creative solutions than they may have time for with shorter iterations. An experienced agile team working on a highly exploratory phase of a project may benefit from a four-week iteration. However, four-week iterations have a feeling of very distinct beginnings, middles, and ends. I don’t like how different the relaxed beginning feels from the more frantic end.
I find two-week iterations to be ideal. The overhead for planning and testing is much more manageable when amortized across two weeks. The first week of a two-week iteration may feel different from the second week, but the difference is not as dramatic as on a four-week iteration. Additionally, most organizations can (with sufficient training) learn not to adjust priorities for two weeks, whereas doing so for four weeks can be very difficult.
Working on endless two-week iterations can be a strain on a team because of the constant pressure to deliver and because a deadline is never further away than next week. My favorite technique to help reduce this strain is follow a macro-cycle of six two-week iterations followed by a one-week iteration. I refer to this cycle as “6 × 2 + 1.” During the two-week iterations, the team works on items prioritized by the product owner. During the one-week iteration, however, the team chooses its own work. That doesn’t mean it’s play time or a week at the beach. Rather, the individuals on the team use this time to focus on what they view as priority work for the project. Programmers may perform refactorings they felt were too risky in the middle of other iterations or experiment with relevant new technologies. A tester may catch up on automating legacy manual tests. An analyst may work on an upcoming large feature that she feels hasn’t received enough attention.
The chance to have one week of work they collectively prioritize themselves can be very reinvigorating for a team. It is important to stress that this one-week iteration is not a dumping ground for the sloppy work of previous iterations. Rather, it is a time when teams may work off some of the technical debt incurred either during early iterations while learning to be agile or from the project’s pre-agile days.
Two Case Studies
To see how to apply these factors, let’s consider two teams: the Napa team and the Goodman team. Each is a real team with only a few minor details changed.
The Napa Project
The seven-person Napa team was working on a client-server desktop application. The application would be used by 600 employees of the company. It would not be sold or used outside the company. Users were located in three cities, one of which was also home to the entire development team. The idea for the product began as a technology update of an existing system that had become expensive to maintain. However, due to changes in the company’s core business, a great deal of new functionality was planned in the project as well. The project had been estimated to take thirteen months, but the company’s rapid growth was creating pressure for an earlier release, even if it included only partial functionality.
For the Napa project, the team chose four-week iterations. We knew the project would be at least six months, so even four-week iterations gave us plenty of opportunities to bring the software to a potentially releasable state so that we could put it in the hands of real users. The project had a fair but not excessive amount of requirements and technology uncertainty. The developers were all experienced in the technologies being used (C++ and Oracle). And even though the new application would have features taking it well beyond what the current application did, we had the current application as a basic model of what was needed.
The project team was collocated with many of the intended users of the system. Most of the users were eager to participate in discussions about what would become their new system. However, the company was growing so quickly that access to these users was partially restricted. We had to be careful not to use too much of their time. Four-week iterations worked well in this situation. Showing them new versions every two weeks would have been too much in this environment. By making a new version available every four weeks, we were able to get more of the users to experiment with the software in a sandbox we had set up for that purpose.
As this was an entirely new application, there was very little overhead of iterating so this wasn’t a factor in the decision. This project was critical to the continued success of the company and had extremely high visibility from the CEO down. For the most part, we were able to establish and maintain priorities for four weeks. Even with four weeks, a sense of urgency was maintained because the team remained aware of the need to get an initial release into users’ hands as quickly as possible.
The Goodman Project
The Goodman team was working on the first version of an enterprise, commercial application. Over the course of the first three years, the company expected to sell no more than 5,000 licenses for the software. However, the product would be expensive, with an average price of $50,000 per user. Eighteen developers were split among two coordinated teams. The Goodman project was expected to take a year, but a preliminary release was planned to go to a handful of customers after six months.
For the Goodman project, the team chose two-week iterations. Because we were targeting an initial release six months out, the team could have used four-week iterations. However, there was a tremendous amount of uncertainty on this project. The company thought it knew who the product’s users would be, but occasional debates about this raged within the company. It wasn’t clear whether the product should be the high-end, high-price system that was initially conceived or whether we should aim for a larger audience at a lower price. This decision was made, remade, and then remade again, but never with sufficient force that the team could feel confident in the answer. There was also a large component of emergent requirements of the “I’ll know it when I see it” variety.
Feedback was difficult to come by on this troubled project. Because it was a commercial product, we had no internal users. Many of the company’s largest customers and prospects were overseas, which complicated matters. There were a number of people within the company who would have been likely users had they worked at our target customer companies, so we used them as proxies for our real users. Because of all the uncertainty and change on this project, we wanted to get feedback as often as possible, which pointed toward shorter iterations.
Priorities could not remain constant for more than a few days in this environment, which also pointed us toward the short, two-week iterations we chose. The test automation team on this project had been in place from the beginning of the project and did a very good job. This helped keep the overhead of iterating low and allowed us to be successful with short iterations. Finally, as the company was a recent start-up and newly public company, it was important that we maintain a sense of urgency. The company had gone public on the promise of some great software coming soon. Short, two-week iterations helped us keep a strong focus on getting that software developed as quickly as possible.
Although it may be tempting to align iterations with the end of the month, I avoid doing so at all costs. If you tie iterations to the ends of months, one out of every three iterations will coincide with the end of a fiscal quarter. Although this is not quite as much of a problem with private companies, there is tremendous pressure in public companies to hit quarterly revenue goals.
I was on one project that had scheduled a significant new release for Friday, March 31, 2000. This release had been a key target for much of the company for nine months (which is the upper limit for how long a single release should be). With two weeks left before the release, our product owner left for a spring-break vacation with his school-age kids. While at Disney World, he valiantly tried to participate in some calls and answer some of our more important questions. Still, his absence came at a critical time, and some important work was not completed in what was to be the final iteration before the big release.
When the product owner returned, we were able to resolve all remaining open issues within a shorter-than-normal one-week iteration. This pushed our release date out from March 31 to April 7. Although a difference of one week may not seem highly critical to a nine-month project, the fact that the delay pushed delivery from one quarter to the next was hugely significant to this publicly traded company. When the planned initial shipment of hundreds of copies didn’t happen on March 31, the revenue from those presales and upgrades could not be recognized until the second quarter. We might as well have delivered on June 30 as April 7.
I haven’t planned a month-end release since then. There are too many unknowns, unknowables, and uncertainties in software development for me to want to risk recognizing revenue by targeting an end-of-the-quarter release.
Summary
Most agile teams work in iterations of two to four weeks. There is no universally correct iteration length that is right for all teams. Rather, each team should consider their unique situation and choose the right iteration length for them. Factors in this decision include
• The length of the release being worked on
• The amount of uncertainty
• The ease of getting feedback
• How long priorities can remain unchanged
• Willingness to go without feedback
• The overhead of iterating
• How soon a feeling of urgency is established
Discussion Questions
1. What is the appropriate iteration for your current project?
2. What differences would you expect on your project if you used one-week iterations? What differences would you expect if you used two-month iterations?