Scrum Sprint

What is a Scrum Sprint, which features characterise it and which rules apply?

Incremental development in short cycles

A Sprint in Scrum is a time defined iteration of constant duration. As a central element in Scrum – the Scrum Guide even speaks of “The heart of Scrum” – the Sprint describes a process with similar or even identical actions with the goal of realising a defined solution.

Scrum itself describes an incremental, iterative and empirical process with few roles, activities and artefacts, which is often used in project management, product and software development.

Characteristics of Scrum Sprints

The following characteristics define a sprint:

  • Each Scrum Sprint starts with Sprint Planning. This is where you decide which requirements from the product backlog are included in the sprint backlog and implemented.
  • The sprint goal is the development of a potentially deliverable increment – also known as Increment of Potentially Shippable Functionality. Theoretically, several deliveries per sprint are also conceivable; only one increment at the sprint end is mandatory.
  • A sprint within a development always has a constant duration – also called a timebox. According to the Scrum Guide, the duration moves at a maximum of 30 days, i.e. one calendar month. In software development Timeboxes between one week and four weeks are usual. This relatively short period is a significant difference to the classic iteration, which does not allow a standardised specification of the duration. The term as such also indicates that this is not a medium- or long-distance race but a short distance – a sprint. In the case of longer sprints, the complexity and thus the risk of undesirable developments could increase. Sprints promote predictability by at least ensuring continuous monitoring and adjustment of progress towards the sprint goal. At the same time, the financial risk is also limited to the duration of the sprint.
  • Every working day, the development team meets at the Daily Scrum to discuss the tasks that have been completed, the tasks that need to be completed, and any obstacles that may be encountered at work. The status of the tasks is often visualised by a taskboard.
  • At the end of the Scrum Sprint, a Sprint Review is carried out in which the team presents the completed work results to the Product Owner and other potential stakeholders.
  • After the sprint is finished, a retrospective is carried out. There the development team reflects on the last sprint and looks at which aspects should be retained in the next sprint and which should be omitted.


Scrum Sprint - the heart of Scrum

Rules of Scrum sprints

In addition, the following rules or points should be observed:

  • No changes will be made during a sprint that could compromise the sprint goal.
  • Quality objectives are not reduced.
  • The scope can be negotiated between the Product Owner and the development team as soon as new findings and lessons learned are available.
  • The Scrum Master takes care of impediments and thus relieves the development team.
  • The Burn-Down-Chart or alternatively the Burn-Up-Chart are tools to visualise the progress within a sprint.
  • The speed of the development team per sprint is called velocity. However, it is not the goal in Scrum to increase velocity, but to get help for future sprint planning.
  • A new sprint starts immediately after the previous sprint.

Determination of the sprint duration

Who determines the duration of the Scrum Sprints? Ideally, all participants should work together, i.e. the development team, the Scrum Master and the Product Owner. But what happens if opinions differ about the duration – who should decide? Opinions vary here:

  • The product owner is predestined to determine the duration, since he “knows” the customers and users and knows the frequency of new increments they expect. In practice, however, it often happens that deliveries in a weekly or monthly rhythm overtax organisations; the increment at the end of the sprint does not have to be delivered, but should simply be “deliverable”. As a result, if the customer expects new increments in short cycles, the product owner could determine the duration.
  • The Scrum Master is predestined to determine the duration, because he ideally knows the development team and its ability best to generate deliverable added value. It is of no use if the product owner defines a duration in terms of the business, but the team cannot achieve this. There may also be technical correlations and necessities that influence the appropriate duration.

Ultimately, it all comes down to the question: what does the market or the customer want and what can the team permanently develop in the appropriate quality? The answer to this question must be found by each organisation individually.

Naming sprints

Usually Scrum Sprints are numbered starting with Sprint 0, then Sprint 1, Sprint 2, and so on. In practice it has been shown time and again that a certain degree of creativity contributes to the strengthening of the team or to team building. Users report on sprints that are named after films or songs, for example. It is only important that, for instance, the film title matches the sprint goal and that the sprint goal is not selected to match the film title. Some choose beer brands, others name sprints after artists, characters from computer games or animals. Anything that pleases is permitted.


An impulse to discuss:

The sprint length is always a compromise between “having to react quickly to changes” and “being able to work in peace”.

What does t2informatik do?

t2informatik - We develop software for great companies

“Scrum Whitepaper”

Everything important about Scrum as a download to take away.

  • We pay attention to your data and will not send you any further mails. One download, one mail. Promised.
  • Date Format: DD slash MM slash YYYY
  • This field is for validation purposes and should be left unchanged.


Here you can find additional information from our blog:

t2informatik Blog: The agile speed lie

 The agile speed lie

t2informatik Blog: The Black Box of Scrum Team Building

The Black Box of Scrum Team Building