What is an Iteration?

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.

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.

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.

• 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.

• 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.

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.

• 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 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.

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.