What is an Iteration?
Iteration
An iteration is one cycle in a repeated pattern of building something, reviewing it, and adjusting before the next cycle starts.
An iteration is one cycle in a repeated pattern: build something, review it against a goal, adjust based on what you learn, then start the next cycle with that adjustment applied. The word describes the pattern itself, not any single framework's version of it.
Iterative work predates Agile by decades. Barry Boehm's spiral model, published in 1986, structured entire software projects as a sequence of iterations, each one a full pass through planning, risk analysis, building, and evaluation. Design teams have iterated on drafts long before anyone called it that: sketch, get feedback, sketch again. Agile and Scrum gave the pattern a name, a fixed length, and a set of ceremonies, but the underlying idea, don't try to get it right in one pass, work in rounds instead, is older and broader than any one methodology.
A Scrum sprint is one well-known implementation of an iteration: fixed length, usually two weeks, with defined roles and ceremonies attached. Plenty of iterative work happens outside Scrum entirely, a designer iterating on three rounds of a logo, a marketing team iterating on ad copy based on click-through data, a Waterfall project running iterative prototyping inside an otherwise linear plan. This entry covers iteration as the general concept; for the Scrum-specific version, see sprint, and for the philosophy iteration belongs to, see agile.
Iteration vs Sprint: What's the Difference
A sprint is one specific, named type of iteration. Every sprint is an iteration; not every iteration is a sprint.
| Iteration | Sprint | |
|---|---|---|
| Scope | Any repeated build-review-adjust cycle | One specific type of iteration, defined by Scrum |
| Length | Varies by context, hours to months | Fixed, typically 1 to 4 weeks |
| Ceremonies | None required | Planning, daily standup, review, retrospective |
| Used in | Design, manufacturing, marketing, software, any iterative process | Scrum teams specifically |
Iteration vs Increment
The two get mixed up because they're tied together, but they answer different questions. An iteration is the cycle itself, the round of work. An increment is what that cycle produces, the piece of finished, usable output added to everything built before it. A design iteration might produce three draft directions; only the one that survives review becomes part of what carries forward. See increment for how this plays out specifically inside Scrum.
The Four-Step Pattern Every Iteration Follows
Regardless of length or field, iterative work repeats the same basic loop:
- Plan: decide the specific goal this cycle is meant to achieve
- Build: do the work toward that goal
- Review: check the result against the goal and gather real feedback on it
- Adjust: change the plan or approach based on what the review revealed, then repeat
Iterative Work vs Linear Work
In a linear process, each phase happens once, in sequence, and reworking an earlier phase is expensive. Iterative work assumes the first pass will be incomplete or wrong in places, and builds the cost of revisiting into the plan from the start.
Neither approach is universally better. Iteration costs more coordination overhead per unit of output, since every cycle needs its own planning and review. Linear work costs more when the initial plan turns out to be wrong, since fixing an earlier phase after later phases depend on it gets expensive fast. See Waterfall for the linear alternative in full.
How Long Should an Iteration Be?
Iteration length is a tradeoff between feedback speed and the size of a useful chunk of work. Too short, and there isn't enough built to get a meaningful reaction. Too long, and problems sit undetected for weeks before the next review catches them.
| Iteration length | Good fit for |
|---|---|
| Hours to a day | Rapid prototyping, a single design draft, A/B ad copy testing |
| 1 to 2 weeks | Most Scrum-style team cycles (sprints) |
| 3 to 6 weeks | Complex feature builds, campaigns with slower feedback loops |
| Quarterly | Strategic initiatives, roadmap-level iterations |
Iteration Outside Software Teams
The pattern shows up anywhere a team can get real feedback and act on it before the next round:
- A marketing team iterating on ad creative weekly based on click-through rate
- A content team iterating on a landing page headline through a series of A/B rounds
- An operations team iterating on an onboarding checklist after every new hire surfaces a gap
- A sales team iterating on a pitch deck after each lost deal, adjusting the sections that came up in the loss
Tracking Iterations in Melororium
Melororium's Project History module keeps a version trail of a project as it moves through rounds, so a team can see what changed between iteration two and iteration three without digging through chat threads. Recurring Projects turns a repeatable iteration, like a monthly content cycle, into a template that spins up the next round automatically.
In Melororium
Track how a project changes across iterations in Melororium
Common mistakes with iteration
What teams get wrong most often, and what to do instead.
- 1
Never closing the loop back to a decision
Producing draft after draft without ever locking in what changed and why, so nobody can tell if the latest round improves on the one before it.
- 2
Confusing more iterations with more progress
Running five rounds on a detail nobody asked about while the core problem stays unaddressed. It feels like effort, but it doesn't move the goal forward.
- 3
Skipping the review step
Starting a new round without checking the last one against its goal first, turning the process into serial guessing instead of feedback-driven refinement.
- 4
No stopping condition
Starting iterative work without deciding in advance what 'good enough' looks like, so the cycle runs until someone gets tired of it rather than until it's done.
Frequently asked questions
Is 'iteration' another word for 'sprint'?
No. A sprint is one specific, named type of iteration, Scrum's version, with a fixed length and defined ceremonies. Iteration is the general term. Teams outside Scrum iterate constantly without calling any of it a sprint.
How do you know when to stop iterating?
Define the goal for the cycle before starting. Once the output meets that goal, or the improvement between rounds drops below what the extra round is worth, stop, rather than letting iteration continue out of habit.
Can a project be both iterative and have a fixed deadline?
Yes. Iterations happen inside a fixed overall deadline all the time. Each cycle narrows the remaining uncertainty; it doesn't remove the need for an end date.
What's the smallest thing worth iterating on?
Anything with a real feedback loop. If a change can't get a meaningful reaction, iterating on it doesn't teach the team anything, so scope each round to something reviewable.
Does Melororium support iterative workflows?
Project History tracks how a project changes across rounds, and Recurring Projects turns a repeatable cycle into a template that generates the next iteration automatically instead of starting from a blank project each time.
