Sprint: Definition, Ablauf und Rolle im IT Service Management

Ein Sprint ist im Scrum-Framework ein Arbeitszyklus fester Länge von höchstens einem Monat, in dem ein Scrum-Team auf ein gemeinsames Sprint-Ziel hinarbeitet und ein nutzbares Inkrement erstellt. So beschreibt es der Scrum Guide in der Fassung vom November 2020. Der Sprint ist dort kein Projektabschnitt neben anderen, sondern der Rahmen für alle übrigen Scrum-Events: Sprint Planning, Daily Scrum, Sprint Review und Sprint-Retrospektive finden innerhalb des Sprints statt. Ein neuer Sprint beginnt unmittelbar nach dem Ende des vorherigen.

Für die Unternehmens-IT ist der Begriff aus zwei Gründen wichtig. Viele Teams, die interne Anwendungen, Schnittstellen oder Plattformen entwickeln, arbeiten in Sprints. Und was in einem Sprint entsteht, landet früher oder später im Betrieb: als Change, als Release, als neuer Service oder als Incident. Wie gut Sprints und Service Management ineinandergreifen, entscheidet deshalb über Stabilität und Liefertempo mit.

Außerhalb von Scrum wird „Sprint“ auch allgemeiner verwendet, etwa für Iterationen anderer agiler Methoden oder für den fünftägigen Design Sprint. Dieser Artikel folgt der Bedeutung im Scrum Guide.

Das Wichtigste in Kürze

• Feste Länge: Ein Sprint dauert höchstens einen Monat und bleibt über mehrere Sprints gleich lang. Kürzere Sprints bedeuten mehr Lernzyklen und ein kleineres Risiko pro Zyklus.
• Ein Ziel: Das Sprint-Ziel beschreibt, warum der Sprint wertvoll ist. Der genaue Umfang darf sich ändern, das Ziel bleibt der Maßstab.
• Vier Events: Sprint Planning, Daily Scrum, Sprint Review und Retrospektive haben feste Höchstdauern.
• Qualität bleibt: Was die Definition of Done nicht erfüllt, gehört nicht zum Inkrement und geht zurück ins Product Backlog.
• Schnittstelle zum ITSM: Inkremente gelangen über Change Enablement und Release Management in den Betrieb. Störungen und Probleme fließen als Einträge ins Product Backlog zurück.

Stand: November 2026 · Fachlich abgeglichen mit dem Scrum Guide 2020, dem Kanban Guide, ITIL 4 und den DORA-Metriken (Quellen am Ende des Artikels)

Wie ein Sprint abläuft: Events, Artefakte und Regeln

Der Scrum Guide legt für jeden Sprint vier Events fest. Die genannten Höchstdauern gelten für einen Sprint von einem Monat. Bei kürzeren Sprints sind die Events in der Regel kürzer.

Die vier Events im Sprint

1. Sprint Planning (höchstens acht Stunden): Das Scrum-Team klärt drei Fragen. Warum ist dieser Sprint wertvoll? Daraus entsteht das Sprint-Ziel. Was kann in diesem Sprint fertig werden? Dazu wählen die Developer gemeinsam mit dem Product Owner Einträge aus dem Product Backlog. Wie wird die Arbeit erledigt? Die Developer planen die Umsetzung, häufig in Arbeitspaketen von höchstens einem Tag.
2. Daily Scrum (15 Minuten): Die Developer prüfen an jedem Arbeitstag zur selben Zeit und am selben Ort den Fortschritt zum Sprint-Ziel und passen ihren Plan für den nächsten Tag an. Form und Technik wählen sie selbst.
3. Sprint Review (höchstens vier Stunden): Scrum-Team und Stakeholder prüfen gemeinsam das Ergebnis und entscheiden, wie es weitergeht. Der Scrum Guide versteht das Review als Arbeitssitzung, die sich nicht auf eine Präsentation beschränken soll.
4. Sprint-Retrospektive (höchstens drei Stunden): Das Team untersucht Zusammenarbeit, Prozesse, Werkzeuge und seine Definition of Done und legt Verbesserungen fest. Mit der Retrospektive endet der Sprint.

Drei Artefakte, drei Verpflichtungen

• Product Backlog mit dem Produkt-Ziel: die geordnete Liste dessen, was am Produkt verbessert werden soll.
• Sprint Backlog mit dem Sprint-Ziel: das Sprint-Ziel, die ausgewählten Einträge und der Plan für ihre Umsetzung.
• Inkrement mit der Definition of Done: das geprüfte, nutzbare Ergebnis. Erst wenn ein Eintrag die Definition of Done erfüllt, wird er Teil des Inkrements.

Was während des Sprints gilt

• Es werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden.
• Die Qualität nimmt nicht ab.
• Das Product Backlog wird bei Bedarf verfeinert.
• Der Umfang kann mit dem Product Owner geklärt und neu verhandelt werden, wenn das Team dazulernt.

Wird das Sprint-Ziel hinfällig, etwa weil sich eine Geschäftsentscheidung geändert hat, kann der Sprint abgebrochen werden. Diese Befugnis hat allein der Product Owner.

Wer am Sprint beteiligt ist

Ein Scrum-Team besteht aus einem Product Owner, einem Scrum Master und den Developern, typischerweise zehn oder weniger Personen. Seit 2020 spricht der Scrum Guide von „Developern“ statt vom Entwicklungsteam. Gemeint sind alle, die am Inkrement arbeiten, also auch Fachleute aus Betrieb, Test oder Fachbereich. Wie Sprints, Rollen und Backlog in Scrum zusammenspielen, erklärt der Glossarartikel Scrum.

Sprint, Kanban, Release und Projektphase: die Unterschiede

Im Alltag werden diese Begriffe oft vermischt. Für die Organisation von IT-Arbeit lohnt sich die Trennung, weil jeder Begriff eine andere Frage beantwortet. Am häufigsten wird der Sprint mit Kanban verglichen:

Der Kanban Guide nennt vier verpflichtende Flussmetriken: die Menge begonnener, aber nicht abgeschlossener Arbeit (Work in Progress), den Durchsatz, das Alter offener Einträge und die Zykluszeit. Viele IT-Organisationen kombinieren beide Ansätze: Entwicklungsteams planen in Sprints, der Service Desk steuert Tickets nach Kanban-Prinzipien. Mehr dazu im Glossar unter Kanban.

Sprint und Release

Ein Sprint ist kein Release-Zyklus. Nach dem Scrum Guide können in einem Sprint mehrere Inkremente entstehen, und ein Inkrement darf schon vor dem Sprint-Ende ausgeliefert werden. Das Sprint Review ist ausdrücklich kein Tor für Auslieferungen. Wann eine Änderung in Produktion geht und mit welchen anderen Änderungen sie gebündelt wird, regelt das Release Management.

Sprint und Projektphase

Laut Scrum Guide lässt sich jeder Sprint als kurzes Projekt betrachten. Anders als eine Phase im klassischen Projektplan endet ein Sprint aber nicht mit einem Zwischenstand auf Papier, sondern mit einem geprüften, nutzbaren Ergebnis. Was danach kommt, legt das Team erst im nächsten Sprint Planning fest, auf Grundlage dessen, was es gelernt hat.

Sprints in der Unternehmens-IT: Entwicklung und Betrieb verzahnen

Sobald ein Team Software oder Infrastruktur liefert, die andere im Betrieb nutzen, berührt jeder Sprint das IT Service Management. Vier Schnittstellen sollten deshalb geregelt sein.

1. Vom Ticket ins Product Backlog

Wiederkehrende Störungen, deren Ursache das Problem Management analysiert hat, und Anforderungen aus Service Requests gehören als Einträge ins Product Backlog. Entscheidend ist der Rückbezug: Der Backlog-Eintrag verweist auf das Problem oder Ticket, damit der Service Desk erkennt, wann ein bekannter Fehler behoben ist, und betroffene Anwender informieren kann.

2. Ungeplante Arbeit im Sprint

Betreuen die Developer auch produktive Systeme, unterbrechen Störungen den Sprint. Bewährt haben sich drei Regeln: Kapazität für Betriebsarbeit wird im Sprint Planning offen eingeplant, die Rufbereitschaft wechselt reihum, und für Prioritäten gilt eine feste Abmachung. Ein Incident mit höchster Priorität geht vor, alles andere wird mit dem Product Owner verhandelt. Das entspricht der Regel des Scrum Guide, dass der Umfang neu verhandelt werden kann, solange das Sprint-Ziel nicht gefährdet ist.

3. Vom Inkrement in die Produktion

Ein fertiges Inkrement ist noch keine genehmigte Änderung am Produktivsystem. ITIL 4 regelt diesen Schritt in der Practice Change Enablement: Risiken werden bewertet, eine zuständige Change Authority autorisiert die Änderung, und ein Change-Zeitplan macht Abhängigkeiten sichtbar. Für häufige, risikoarme Auslieferungen eignen sich Standard-Changes, die einmal bewertet und dann vorab genehmigt sind. Automatisierte Tests in der Auslieferungskette ersetzen dann die Einzelfreigabe, nicht die Kontrolle. Risikoreiche Änderungen durchlaufen weiterhin eine eigene Bewertung (siehe Change Management).

4. Wissen an den Service Desk übergeben

Die Definition of Done kann betriebliche Punkte enthalten, etwa einen Artikel in der Knowledge Base für den Service Desk, aktualisierte Einträge in der CMDB und eingerichtete Überwachung. Dann erfährt der Service Desk von einer neuen Funktion nicht erst durch die ersten Anrufe.

Standardisieren, wenn mehrere Teams liefern

Angenommen, ein Unternehmen lässt acht Scrum-Teams an internen Anwendungen arbeiten, und jedes Team hat eigene Regeln, wann etwas fertig ist. Der Scrum Guide sieht für diesen Fall eine klare Regel vor: Ist die Definition of Done Teil der Unternehmensstandards, müssen alle Scrum-Teams sie mindestens erfüllen. Teams, die am selben Produkt arbeiten, verwenden ohnehin dieselbe Definition. Eine unternehmensweite Mindestfassung mit Punkten zu Betrieb, Sicherheit und Dokumentation schafft vergleichbare Übergaben an den Betrieb, ohne den Teams ihre Arbeitsweise vorzuschreiben.

Was ky2help^® dafür bereitstellt

Incident, Problem, Change Enablement und Release Management gehören zu den 13 Practices, für die ky2help^® von PeopleCert nach ITIL^® 4 akkreditiert ist. Arbeiten Entwicklungsteams mit Jira, gehört eine Schnittstelle zu Jira zum Standard, weitere Systeme lassen sich über die REST-API anbinden. Genehmigungsabläufe passen Sie im Prozessdesigner per Drag-and-Drop an, ohne Programmierung. Wie der Service Desk selbst agiler organisiert werden kann, beschreibt der Beitrag Der agile Service Desk.

Change Management ansehen

Kennzahlen und typische Fehler bei Sprints

Was sich sinnvoll messen lässt

• Sprint-Ziel erreicht: Ja oder nein, betrachtet über mehrere Sprints. Diese Größe sagt mehr als die Zahl erledigter Einträge, weil sie den Zweck des Sprints abbildet.
• Prognosehilfen: Viele Teams schätzen den Aufwand in Story Points und messen, wie viel sie pro Sprint schaffen (Velocity). Beides kommt im Scrum Guide nicht vor. Er nennt Burn-down- und Burn-up-Diagramme oder kumulative Flussdiagramme als mögliche Hilfen und betont, dass sie Erfahrung aus dem tatsächlichen Verlauf nicht ersetzen. Solche Werte taugen zur Planung im Team, nicht zum Vergleich zwischen Teams.
• Liefer- und Stabilitätskennzahlen: Das Forschungsprogramm DORA misst Software-Auslieferung mit fünf Werten: Durchlaufzeit einer Änderung, Häufigkeit der Deployments, Wiederherstellungszeit nach einem fehlgeschlagenen Deployment, Change-Fehlerquote und Anteil ungeplanter Nacharbeits-Deployments. Sie verbinden die Arbeit im Sprint mit ihren Folgen im Betrieb.
• Ungeplante Arbeit: Der Anteil der Sprint-Kapazität, der in Störungen und Ad-hoc-Anfragen fließt. Steigt er dauerhaft, ist das ein Hinweis auf Qualitätsprobleme oder auf eine zu knappe Betriebsorganisation.

Typische Fehler

• Sprint-Ziel als Sammelliste: Ein Ziel wie „alle Einträge im Sprint Backlog erledigen“ gibt keine Richtung. Ein gutes Sprint-Ziel beschreibt einen Nutzen, zum Beispiel „Neue Mitarbeitende können ihr Notebook selbst über das Portal anfordern“.
• Qualität als Puffer: Wird bei Zeitdruck an Tests oder Dokumentation gespart, verletzt das die Regel, dass die Qualität nicht abnimmt. Die Folgen landen beim Service Desk.
• Stabilisierungs-Sprints: Ein eigener Sprint nur zum Testen und Nacharbeiten zeigt, dass die Definition of Done zu schwach ist. Inkremente sollen in jedem Sprint fertig sein.
• Review als Abnahmetermin: Wird das Review zur reinen Vorführung oder zum formalen Freigabetermin, fehlt das Feedback, und Auslieferungen stauen sich bis zum Sprint-Ende.
• Retrospektive ohne Folgen: Laut Scrum Guide werden die wirksamsten Verbesserungen so bald wie möglich angegangen. Sie können sogar direkt ins Sprint Backlog des nächsten Sprints aufgenommen werden.
• Wechselnde Sprint-Längen: Wer einen Sprint bei Bedarf verlängert, verliert den Takt und die Vergleichbarkeit zwischen den Sprints.

Häufige Fragen zum Sprint

Wie lange dauert ein Sprint?

Ein Sprint dauert höchstens einen Monat. Innerhalb dieser Grenze legt das Scrum-Team die Länge fest und behält sie über mehrere Sprints bei. Kürzere Sprints ermöglichen mehr Lernzyklen und begrenzen das Risiko, Aufwand in die falsche Richtung zu investieren.

Was passiert, wenn das Sprint-Ziel nicht erreicht wird?

Der Sprint endet trotzdem zum geplanten Zeitpunkt, er wird nicht verlängert. Einträge, die die Definition of Done nicht erfüllen, gehen zurück ins Product Backlog. Im Sprint Review und in der Retrospektive klärt das Team, wie es dazu kam und was es im nächsten Sprint anders macht.

Wer darf einen Sprint abbrechen?

Nur der Product Owner, und nur dann, wenn das Sprint-Ziel hinfällig geworden ist. Ein Abbruch ist die Ausnahme, weil er den Takt unterbricht und eine neue Planung erfordert.

Darf man während eines Sprints neue Aufgaben aufnehmen?

Ja, solange das Sprint-Ziel nicht gefährdet wird. Der Umfang kann mit dem Product Owner geklärt und neu verhandelt werden. Dringende Betriebsstörungen fangen viele Teams über eine eingeplante Kapazitätsreserve ab.

Was ist der Unterschied zwischen Sprint und Iteration?

Iteration ist der allgemeine Begriff für einen wiederholten Arbeitszyklus in agilen Methoden. Sprint ist die Bezeichnung in Scrum und an feste Regeln gebunden: höchstens ein Monat, ein Sprint-Ziel, vier Events und eine Definition of Done.

Wie passen Sprints und ITIL zusammen?

Scrum regelt, wie ein Team Inkremente erstellt. ITIL-Practices wie Change Enablement und Release Management regeln, wie Änderungen sicher in den Betrieb gelangen. Risikoarme, wiederkehrende Auslieferungen lassen sich als vorab genehmigte Standard-Changes behandeln, sodass nicht jede Auslieferung einzeln freigegeben werden muss.

Quellen und weiterführende Artikel

Quellen

• Ken Schwaber, Jeff Sutherland: The 2020 Scrum Guide (englisch) und deutsche Fassung (PDF)
• Daniel Vacanti, John Coleman: The Kanban Guide (Fassung Mai 2025)
• AXELOS/PeopleCert: ITIL 4 Practice Guide Change Enablement
• AXELOS/PeopleCert: ITIL 4 Practice Guide Release Management
• DORA (Google Cloud): DORA’s software delivery performance metrics

Weiterlesen im Glossar und in der Wissenswelt

• Scrum und Backlog
• Kanban und DevOps
• Continuous Integration und Change Management
• Der agile Service Desk und Was ist ITIL Release Management?