Timeboxed Iterative Development

Iteration timeboxing is the practice of fixing the iteration end date and not allowing it to change. An overall project may be timeboxed as well. If it eventually appears that the chosen requests (the scope) for the iteration can't be met within the timebox, then rather than slip the iteration end date, the scope is reduced (placing lower priority requests back on the wish-list), so that the partial, growing system always ends in a stable and tested state on the original planned iteration end date. See Figure 2.3.

Figure 2.3. timeboxing

multi-site timeboxed iterations

overlapping activities across timeboxes

It is important that timeboxing is not used to pressure developers to work longer hours to meet the soon-coming deadline. If the normal pace of work is insufficient, do less.

In most IID methods, not all timebox lengths need be equal. The first iteration may be four weeks, the second iteration three weeks, and so forth. On the other hand, the Scrum method recommends that each timebox be exactly 30 calendar days. As mentioned, most IID methods recommend an iteration timebox between one and six weeks.

iteration length

what day to end a timebox?

A three-month or six-month timeboxed "iteration" is extraordinarily long and usually misses the point and value; research shows that shorter steps have lower complexity and risk, better feedback, and higher productivity and success rates. That said, there are extreme cases of projects with hundreds of developers where a three-month iteration is useful because of the overhead.

All the modern IID methods (including Scrum, XP, and so forth) either require or strongly advise timeboxing the iterations.