A Fixed Schedule for Shippable Work
Timeboxed iterations are a project planning technique, most commonly associated with agile software development, that split work into fixed calendar periods. The team first breaks the product's visible functionality into user stories, then divides time into iterations of equal length—one week is a typical example. Stories are allocated to those iterations, with rough estimates used to judge how many each iteration can hold.
The defining constraint of a timeboxed iteration is that its end date cannot slip. There is no mechanism for extending an iteration to finish leftover stories. Any story that isn't complete by the end of the iteration is treated as not-done, and the remaining work becomes the basis for a new story scheduled in a later iteration.
Calculating Capacity
A pragmatic way to set an iteration's capacity is to look at what the team actually completed last time. Setting future capacity to match the previous iteration's throughput creates a self-calibrating feedback loop. For steadier numbers, it's common to look across several iterations rather than just one, and taking the average of the last few is a natural choice. A better option, though, is to take the minimum of recent iterations. Building capacity on the minimum gives the team useful slack that can absorb the unpredictable bumps that inevitably occur.
Iterations vs. Continuous Flow
Timeboxed iterations aren't the only scheduling model. In continuous flow, there are no iterations at all: each time a story is finished, the team simply picks the next story from a prioritized backlog. That approach eliminates the overhead of assigning stories to fixed periods, which some teams find attractive. But iterations bring a regular cadence to work and create a rhythm many people value.
Diagnostic Value of the Deadline
Beyond scheduling, the real benefit of iterations is that they force problems into the open. An iteration boundary acts as a natural stopping point where overruns become visible, producing reliable feedback on the accuracy of estimates. If a team consistently fails to finish its stories, or if the end of each iteration is a frantic scramble, that's evidence of deeper problems in how the team operates. This alarm signal matters most for teams struggling with weak engineering practices. The proper response—increasing slack so the team can address the root causes—is frequently neglected.
Further Reading
Most agile planning literature assumes timeboxed iterations. For current guidance, The Art of Agile Development covers iteration length selection, capacity calculation, tracking, and handling urgent requests; the task planning chapter is available online at James Shore's site. An older but historically relevant reference is Planning Extreme Programming, co-written with Kent Beck early in the century—its prose may be unmatched, but The Art of Agile Development is the more useful modern recommendation.
