1. Home
  2. Smartpedia
  3. Scrum Sprint

Scrum Sprint

Smartpedia: A Sprint in Scrum is an iteration of constant duration, i.e. a process with similar actions and the goal to realise a defined solution.

Sprint – incremental development in short cycles

Scrum is a framework for the development of software, products and services. It describes an incremental, iterative and empirical procedure with few accountabilities, artifacts and 5 events:

  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

The Sprint is a central element in Scrum; the Scrum Guide even speaks of the “heartbeat of Scrum”. It is a time-defined iteration of constant duration, with similar or even the same actions, and the goal of realising a defined solution. 

Scrum Sprint - incremental development in short cycles

Characteristics of Scrum Sprints

The following characteristics define a Sprint:

  • All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective, takes place within Sprints. This makes the Sprint practically a container for the other 4 events.
  • Every Scrum Sprint starts with Sprint Planning. There the Sprint Goal is defined and it is determined which Product Backlog Items will be included in the Sprint Backlog and realised in the Sprint. Afterwards the Scrum Team commits itself to the Sprint Goal.
  • The result of the Sprint is a potentially shippable Increment – also called Increment of Potentially Shippable Functionality. Theoretically, several deliveries per Sprint are possible, but only one Increment to the end of the Sprint is mandatory.
  • A Sprint always has a constant duration – also called Timebox. According to the Scrum Guide the duration ranges from one week to a maximum of one month. This relatively short period of time is an essential difference to the classical iteration, which does not define a standardised specification of duration. Also the term as such indicates that it is not a medium or long distance run but a short distance – a Sprint – in the figurative sense. Longer Sprints could increase the complexity and thus the risk of mistakes. Sprints promote predictability by at least ensuring that progress towards the Sprint Goal is continuously monitored and adjusted. At the same time, the financial cost risk is also limited to the duration of the Sprint.
  • Every working day, the developers (and, if applicable, the Scrum Master and the Product Owner) meet for the Daily Scrum and discuss the completed and upcoming tasks to achieve the Sprint Goal, as well as possible obstacles in the work. The status of the tasks is often visualised via taskboard.
  • At the end of the Scrum Sprint, a Sprint Review is conducted, in which the team presents the completed work results to important stakeholders (and as the representative of the stakeholders to the Product Owner).
  • After the Review a Retrospective is carried out.There the Scrum team reflects on the last sprint and looks at which aspects should be retained in the next sprint and which should be left out.


Rules for Scrum Sprints

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

  • During a sprint no changes are made that could endanger the Sprint Goal.
  • Quality Goals are not reduced.
  • The scope can be negotiated between the product owner and the developers as soon as new findings and lessons learned are available.
  • The Product Owner is the one who could abort a Sprint if the Sprint Goal turns out to be obsolete.
  • Ideally, the developers should remove possible impediments on their own. This is a step towards self-management. The Scrum Master only helps if necessary.
  • 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, the Goal in Scrum is not to increase the Velocity, but to use it as an aid for future Sprint Plannings.
  • A new Sprint starts immediately after the completion of the previous Sprint.


The Sprint Duration

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

  • The Product Owner is predestined to determine the duration because he “knows” the customers and users and knows in which frequency they expect new Increments. 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 only be “deliverable”. This means: if the customer expects new Increments in short cycles, then the Product Owner could determine the duration.
  • The Scrum Master is predestined to determine the duration, because ideally he knows the developers and their ability to create deliverable added value best. It is of no use if the Product Owner defines a duration in terms of the business, but the team is unable to do so. It is also possible that there are technical contexts and necessities that have an influence on a suitable duration.

Ultimately, it comes down to the question: what does the market or the customer want and what can the team develop in the long term with the appropriate quality? Every organisation must find the answer to this question for itself.

The Naming of Sprints

There are several ways to name Sprints. In practice, it has been shown time and again that a certain amount of creativity helps to strengthen the team or to build a team:

  • Usually Scrum Sprints are numbered, starting with Sprint 0, then Sprint 1, Sprint 2, etc.
  • Sprints could also be named after films or songs. In such a case, it would only be important that the film title matches the Sprint Goal, for example, and not that the Sprint Goal is selected to match the film title.
  • Alternatively, beer brands, artists, characters from computer games or animals can be used as name givers.

Allowed is what you like.

Scrum Whitepaper as Download

Download the Scrum Whitepaper for free now.

Everything important about the framework at a glance.

  • Events
  • Accountabilities
  • Artefacts
  • Values
  • Benefits
  • Tips

Knowledge on 13 pages to take away.

Impulses to discuss:

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

Can you imagine situations in which so-called “Nested” Sprints can be useful?


Jeff Sutherland, in his book “Scrum: The Art of Doing Twice the Work in Half the Time“, explained how the term Sprint came about: “„… And so my team embarked on what we called ‚Sprint‘. We called them because the name evoked a quality of intensitiy. We were goint to work all out for a short period of time and then stop to see where we were“. 

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

t2informatik Blog: Remote Sprint Review in Large-Scale Scrum (LeSS)

Remote Sprint Review in Large-Scale Scrum (LeSS)