1. Home
  2. Smartpedia
  3. Iteration

What is an Iteration?

Smartpedia: An iteration describes a repetitive process of similar or even identical actions with the goal of realising a defined solution.

Iteration – a process with repetitive actions

Iteration, from the Latin for “to repeat”, refers to a process of similar or identical actions that produces a defined solution. Iteration is used in mathematics, linguistics, computer science and product development or software development. In computer science, it refers to either the repeated execution of instructions in a loop or the repeated access to data structures.

Iterations in software development

In software development, iteration is used in different ways:

Variant 1: It describes the repeated running through of entire development cycles. A classic development cycle is often divided into individual project phases such as preparation, implementation, testing, operation and maintenance with corresponding milestones at the end of the phase. Thus, the implementation as a whole could be repeated until an internal release for testing by a separate test department takes place.


Variant 2: It describes the repeated passing through of individual development steps within a phase. Individual phases within the realisation, such as the analysis or the design, usually do not have to be repeated. Implementation, on the other hand, is often divided into sections – iterations – in practice. An iteration therefore describes a period in which actions such as the programming of new functions are repeated. In such a procedure, the results of several iterations are combined to releases.

What is important is that the repetition does not refer to a concrete function that is developed again and again, but to the action, i.e. the programming as such. This means that similar actions are performed in iterations, but the requirements, features, epics, etc. to be realised differ.

Variant 3: The repeated interaction of several phases – e.g. between realisation and testing – can be understood as a special form. A product is realised and then tested, followed by further development and testing. This process is repeated until the product has reached the desired quality and can be put into operation.

In product and software development, we often speak of an iterative-incremental approach. Iterative refers to a temporally and technically self-contained period of time in which additional functionality is developed step by step (incrementally).

Questions in the context of iterations

Here are some questions with answers in the context of iterations:

How long does an iteration typically take?

Due to the different interpretations of an iteration, it is not possible to generally determine how long an iteration lasts or how often it is repeated. Corresponding definitions must be made on a project-specific basis.

In Scrum, the best-known representative of agile software development, iterations are called sprints. They are fixed-length events of one month or less, with a new sprint starting immediately after the completion of the previous sprint. Theoretically, a sprint could last only one day, but in practice it usually lasts a week, two, three or four weeks. In numerous publications there are references to two weeks being “usual”.

The V-Modell XT as a process model of German authorities does not have such a specification; there, iterations in the course of tailoring are defined statically at the beginning of the project or dynamically in the course of the project with time intervals to be determined. The time intervals are based on the content – an essential difference to Scrum, because there the content is defined in such a way that it can be realised in the fixed time intervals.

How do you determine the duration of an iteration?

It can be challenging to determine the duration of an iteration, especially as different factors can be taken into account in different ways:

  • The amount of continuous tasks that need to be done. Example: Implemented features need to be documented. The documentation is done in German and has to be approved technically and semantically. Consequently, the duration of this recurring activity must be taken into account when planning the iteration period. Assuming that the documentation would also have to be done in English and Spanish. What impact would this have on the duration? Would it increase to 3 days, or is there capacity available and the tasks can be done in parallel, increasing the effort but not the duration?
  • The number of people or parties involved. Example: How many people will be involved in a review? How many results are taken from other developments? The more people involved, the greater the effort and probably the duration within an iteration.
  • The availability of people involved. Example: An important stakeholder is only available once in 14 days. An iteration duration of one week therefore seems pointless. A duration of 2 or possibly 4 weeks would be more obvious.

To determine the iteration length, it is advisable to,

  • estimate the duration of individual tasks,
  • keep an eye on the duration of individual events – Scrum defines Sprint Planning, Sprint Review and Retrospective, for example,
    the availability of resources and
  • dependencies on other projects or developments, and to
  • include coordination paths and processes.

Furthermore, it makes a lot of sense to develop a common feeling in the team about the “ideal” duration. It is advisable to start with a slightly longer iteration, to gain experience and to determine after a few runs whether the iteration is well timed, or whether it should be shortened or extended.

Why are iterations with a constant duration useful?

In terms of comparability of results, it makes sense to plan iterations with the same duration, regardless of the approach used – e.g. Scrum, Kanban, SAFe or V-Modell XT. However, comparability is not about competition with other teams, but about parameters that facilitate future task planning within a team.

Is it possible to change the duration of an iteration?

In principle, it should be possible to adjust the duration based on experience. However, the implications should be considered:

  • Are key stakeholders still available on a regular basis if they are now needed once a week instead of once a fortnight for planning or a review?
  • What are the dependencies on other projects or sub-developments? Does the planned extension of iterations mean that other areas will have to wait longer than before for deliveries?
  • How will communication with customers change?
  • What impact will the change have on internal planning and team-internal comparability of velocity?

Of course, it is advisable to make such a decision carefully. Regular changes – from one week, to three weeks, then two weeks, etc. – should certainly be avoided.

How do you name iterations?

Usually, iterations are given numbers. On the one hand, this is practical and relatively easy to understand (“We are currently developing XY 10.1”), but on the other hand it is sometimes a bit “boring”. In itself, there are no limits to creativity, so naming can also be done with

  • film or music titles,
  • beer brands,
  • artist names,
  • animals or
  • characters from computer games.

Basically, when naming, those involved should pay attention to what goal is being pursued: Internal fun, creating a community or communication with other areas or even customers?

“How far along are you with Rambo III?” probably seems funny within the company, a statement in the direction of the customer “Unfortunately, Rambo III is still a little delayed” probably seems strange. Ergo: It depends on the purpose and who interacts with the name and how.

How do you measure the speed of development of an iteration?

Velocity is probably the best-known measure of the speed of iterations or sprints. It is based on realised story points. Story points are a unit for describing the size of a user story and represent the development effort and the factors that influence this effort. Velocity is a team-internal planning and risk control tool that addresses a steady pace that the client, developers and users can maintain over an indefinite period of time. It is not a measure to compare teams in an organisation. Such a comparison would almost inevitably lead to an inflation of story points.

There are a number of alternative metrics such as cycle time, mean time to repair or time to value.

What is the difference between iteration and sprint?

To answer this question, a look at the respective definitions helps:

  • An iteration describes a repetitive process of similar or even identical actions with the goal of realising a defined solution.
  • A Scrum Sprint is an iteration of constant duration and similar actions, as well as the goal of realising a defined solution.

Both terms are therefore very close to each other, whereby the Scrum Guide, which describes the rules of Scrum, defines the sprint with a maximum duration of 4 weeks. Compared to traditionally or classically planned projects, whose iterations often take several months, the sprint is fast. The point is to work in shorter cycles to get early feedback from stakeholders and consequently steer developments in the appropriate direction.

How do you integrate customer or user feedback into the iteration process?

Stakeholders are all persons or organisations that are directly or indirectly affected by the activities of a company or have an interest in these activities. In other words: customers, guests, users, consumers, etc.

How do you best integrate these stakeholders into the iteration process? The answer is:

  • early and
  • continuously.

Early feedback helps to align expectations and avoid possible undesirable developments. Continuous feedback helps to develop a product that is useful for stakeholders.

Stakeholder communication addresses the regular exchange between a company and its stakeholders. It differs in type, means, frequency and timing. And it is very important because people pursue individual goals. Conflicts can easily arise between the goals of individual stakeholders, which makes early and continuous feedback all the more important.

What is iterative planning?

Iterative planning describes a procedure in which the entire project is not planned only once at the beginning of the project, but planning is done repeatedly during the course of the project. Especially if projects are complicated and/or complex, i.e. parameters such as parameters, requirements, goals change during the course of the project, it makes sense to take the corresponding findings into account step by step. Of course, it still makes sense to define a path towards the defined goal at the beginning of the project, but the planning of individual sections and activities is done iteratively “on sight” so that changes can be reacted to flexibly, feedback integrated and results continuously refined.


Feel free to share or link to the content on this page.

In software development, there is also the term iterator. In simple terms, it is a pointer – e.g. a cursor – with which elements of a set can be traversed.

Here you will find additional information from our Smartpedia section:

Smartpedia: What is Application Lifecycle Management?

What is Application Lifecycle Management?

Smartpedia: What is a Definition of Done?

What is a Definition of Done?

Smartpedia: What is Continuous Delivery?

What is Continuous Delivery?