An iteration (a fixed, short period in which a team completes a defined chunk of work) is a fundamental agile building block, and the reason for time-boxing work at all, rather than working continuously toward a larger goal, is worth being explicit about.
The core function: forced, regular checkpoints
An iteration's value isn't really about the time period itself: it's about creating a forced, recurring checkpoint where the team produces something reviewable and stakeholders engage with actual progress, rather than waiting for a distant final delivery date. Without this, both team and stakeholders can drift for a long time without a forcing function that surfaces problems while they're still cheap to address.
Why "short" matters specifically
A twelve-week iteration provides some checkpoint benefit, but allows twelve weeks of potential drift before the next reality check. Shorter iterations trade a bit of planning overhead for meaningfully faster detection of problems, usually the better trade for genuinely uncertain work.
What an iteration actually delivers
For an iteration to serve its purpose, it needs to produce something real and reviewable at the end: not simply a status update, but an actual increment stakeholders can engage with directly.
The discipline iterations impose on scope
Iterations force work to be broken down small enough to genuinely complete within the timeframe, which in turn forces continuous decomposition of larger initiatives. Teams that struggle to fit meaningful work into their iteration length often have a decomposition problem more than an iteration-length problem.
Iterations versus Sprints: a note on terminology
In Scrum, an iteration is called a Sprint and comes with a defined set of accompanying events and artifacts. "Iteration" is the more general agile term, applicable across frameworks using time-boxed cycles without necessarily adopting Scrum's specific structure. The underlying purpose (forced, regular checkpoints against real, reviewable output) is shared across both terms.