Was ist ein Sprint in Agile? Dauer, Events und Beispiele

Was ist ein Sprint in Agile?

A Sprint ist ein Zeitraum fester Länge von höchstens einem Monat, in dem ein agiles Team auf ein einziges Sprint-Ziel hinarbeitet und mindestens ein nutzbares Inkrement des Produkts erstellt. Sprints folgen lückenlos aufeinander, und alle Aktivitäten zu Planung, Abstimmung, Review und Verbesserung des Produkts finden in ihnen statt.

Der Begriff stammt aus Scrum, dem am weitesten verbreiteten agilen Framework. Der Scrum Guide (Ausgabe 2020, nach wie vor die aktuelle offizielle Version) beschreibt Sprints als den Herzschlag von Scrum, in dem Ideen in Wert verwandelt werden. Andere agile Methoden verwenden für dieselbe Idee das Wort Iteration , und viele Teams, die Scrum nicht streng folgen, sagen trotzdem „Sprint“.

Wie auch immer er heißt, ein Sprint hat fünf prägende Merkmale:

• Feste Länge. Die Länge wird im Voraus festgelegt und bleibt von Sprint zu Sprint gleich, sodass das Team sein Tempo kennenlernt.
• Ein Ziel. Jeder Sprint hat ein Sprint-Ziel: ein einziges Ziel, das erklärt, warum sich der Sprint lohnt.
• Ein nutzbares Ergebnis. Am Ende hat das Team ein Inkrement, das die Definition of Done erfüllt, auch wenn es noch nicht ausgeliefert wurde.
• Nahtlos aufeinander. Ein neuer Sprint beginnt unmittelbar nach dem Ende des vorherigen.
• Alles findet darin statt. Planung, tägliche Abstimmung, Refinement, Review und Retrospektive finden alle innerhalb des Sprints statt, nicht davor oder danach.

Kurze, feste Zyklen machen Agile empirisch: Alle paar Wochen betrachten das Team und seine Stakeholder echte, funktionierende Ergebnisse und entscheiden, was als Nächstes zu tun ist.

Sprint vs. Iteration vs. Scrum

Diese Begriffe werden oft verwechselt. Die Tabelle zeigt, wie sie zusammenhängen.

Kurz gesagt: Ein Sprint ist eine Form der Iteration, und Scrum ist das Framework, das dem Sprint seine Regeln gibt. Hinter beidem steht die iterative und inkrementelle Entwicklung: das Produkt in kleinen Scheiben bauen und es in jedem Zyklus verbessern.

Wie lang ist ein Sprint?

Der Scrum Guide legt nur eine Regel fest: Ein Sprint dauert höchstens einen Monat. Innerhalb dieser Grenze entscheidet das Team. In der Praxis arbeiten die meisten Teams mit Sprints von einer bis vier Wochen, und zwei Wochen sind mit Abstand die häufigste Wahl, weil sie schnelles Feedback und den Aufwand für Planung und Review gut ausbalancieren.

So wählen Sie die Sprint-Länge

Wählen Sie die kürzeste Länge, in der das Team etwas Sinnvolles und Fertiges liefern kann. Berücksichtigen Sie dann:

• Wie schnell sich Dinge ändern. Je volatiler der Markt oder die Anforderungen, desto kürzer der Sprint.
• Wie lange Feedback warten kann. Wenn Stakeholder jede Woche Fortschritt sehen müssen, ist ein vierwöchiger Sprint zu lang.
• Größe der Einträge. Wenn die meisten Backlog-Einträge mehr als ein paar Tage dauern, teilen Sie sie auf, bevor Sie den Sprint verlängern.
• Release- und Testbeschränkungen. Integration, Compliance-Prüfungen oder Lieferzeiten für Hardware können sehr kurze Sprints unpraktikabel machen.
• Abstimmung. Teams, die am selben Produkt arbeiten, teilen meist dieselbe Sprint-Länge und dasselbe Startdatum.

Die Sprint-Länge ändern

Halten Sie die Länge mindestens über mehrere Sprints stabil, damit Ihre Velocity und Prognosen aussagekräftig sind. Ändern Sie sie bewusst in einer Retrospektive, nicht mitten im Sprint, und verlängern Sie nie einen einzelnen Sprint, weil Arbeit unfertig ist. Die Scrum-spezifischen Regeln finden Sie in unserem Leitfaden zum Scrum-Sprint-Zyklus.

Die Bausteine eines Sprints

Drei Dinge geben einem Sprint seine Form: ein Ziel, ein Plan und ein Ergebnis.

Sprint-Ziel

Das Sprint-Ziel ist das eine Ziel des Sprints. Es entsteht im Sprint Planning und ist das Commitment der Developers. Ein gutes Sprint-Ziel beschreibt ein Ergebnis, keine Liste von Tickets; so behält das Team Spielraum, die Detailarbeit anzupassen, während es dazulernt.

• Schwach: „Tickets 412, 415, 419 und 420 abschließen.“
• Besser: „Wiederkehrenden Kunden einen Checkout in einem Schritt ermöglichen, damit wir testen können, ob das die Zahl abgebrochener Warenkörbe senkt.“
• Beispiel außerhalb der Software: „Die Landingpage der Frühjahrskampagne und die ersten beiden E-Mails live schalten, damit der Vertrieb am Montag mit der Ansprache beginnen kann.“

Sprint Backlog

Der Sprint Backlog besteht aus dem Sprint-Ziel, den für den Sprint ausgewählten Product-Backlog-Einträgen und dem Plan der Developers für deren Lieferung. Es gehört den Developers, die es während des gesamten Sprints aktualisieren, damit alle die verbleibende Arbeit sehen.

Inkrement und Definition of Done

Ein Inkrement ist ein Schritt in Richtung Produktziel, der nutzbar ist und die Definition of Done erfüllt. Arbeit, die die Definition of Done nicht erfüllt, ist nicht Teil des Inkrements, egal wie nah sie daran ist. In einem Sprint können mehrere Inkremente entstehen, und sie können jederzeit ausgeliefert werden; das Sprint Review ist kein Release-Tor.

Die Events innerhalb eines Sprints

Der Sprint ist ein Container für vier weitere Events. Die Timeboxen unten sind die Höchstwerte, die der Scrum Guide für einen einmonatigen Sprint angibt; bei kürzeren Sprints sind die Events meist kürzer.

Sprint Planning eröffnet den Sprint. Der Product Owner erläutert, welche Ziele am wichtigsten sind, die Developers wählen Einträge aus, die sie fertigstellen zu können glauben, und gemeinsam formuliert das Team das Sprint-Ziel. Anschließend planen die Developers, wie sie die Arbeit erledigen, oft indem sie Einträge in Aufgaben von höchstens einem Tag zerlegen.

Das Daily Scrum ist ein 15-minütiger Abgleich für die Developers. Es ist kein Statusbericht an eine Führungskraft. Die entscheidende Frage lautet: Sind wir auf Kurs zum Sprint-Ziel, und was ändern wir heute, falls nicht?

Das Sprint Review ist eine Arbeitssitzung, keine Präsentation. Das Team zeigt, was fertig (Done) ist, die Stakeholder geben Feedback, und die Gruppe bespricht die nächsten Schritte, die in das Product Backlog einfließen.

Die Sprint-Retrospektive schließt den Sprint ab. Das Team wählt wenige konkrete Verbesserungen aus, und die wichtigsten können in das nächste Sprint Backlog aufgenommen werden.

Backlog Refinement ist kein Event, sondern eine fortlaufende Aktivität während des Sprints. Das Team klärt, teilt und schätzt anstehende Einträge, damit das nächste Sprint Planning zügig verläuft.

Agenden und Moderationstipps für jedes Meeting finden Sie in unserem Leitfaden zu Scrum-Zeremonien.

Wer in einem Sprint was tut

Ein Scrum Team hat drei Verantwortlichkeiten. Alle drei sind nötig, damit ein Sprint funktioniert.

Beachten Sie: Niemand weist den Developers Aufgaben zu; sie organisieren die Arbeit selbst.

So planen und führen Sie einen Sprint durch, Schritt für Schritt

Dies ist unsere empfohlene Reihenfolge für ein Team, das seine ersten Sprints durchführt. Sie folgt dem Scrum Guide, ergänzt um praktische Gewohnheiten.

1. Das Product Backlog vorbereiten. Stellen Sie vor der Planung sicher, dass die obersten Einträge geordnet, klar und klein genug sind, um im Sprint fertig zu werden. Dafür sorgt das Refinement im vorherigen Sprint.
2. Kapazität prüfen. Erfassen Sie Urlaube, Schulungen und andere Verpflichtungen, damit Sie wissen, wie viel Zeit das Team tatsächlich hat. Unser Leitfaden zur agilen Kapazitätsplanung erklärt, wie das geht.
3. Das Sprint-Ziel vereinbaren. Im Sprint Planning schlägt der Product Owner das Ziel vor, und das Team formt daraus einen klaren Satz.
4. Die Arbeit auswählen. Die Developers ziehen Einträge von oben aus dem Backlog, bis eine realistische Last erreicht ist, und orientieren sich dabei an der jüngsten Velocity oder am Durchsatz.
5. Das Wie planen. Zerlegen Sie die Arbeit der ersten Tage in Aufgaben und vereinbaren Sie, wer womit beginnt. Sie müssen nicht jede Aufgabe im Voraus planen.
6. In kleinen Paketen arbeiten. Stellen Sie Einträge fertig, bevor Sie neue beginnen. Wenn jemand blockiert ist, helfen andere; das nennt man Swarming.
7. Täglich überprüfen. Nutzen Sie das Daily Scrum und ein sichtbares Scrum-Board, um Risiken für das Sprint-Ziel früh zu erkennen.
8. Anstehende Arbeit verfeinern. Verwenden Sie in jedem Sprint etwas Zeit darauf, die nächsten Einträge vorzubereiten; frühere Ausgaben des Scrum Guide nannten dafür in der Regel höchstens 10 % der Teamkapazität, und viele Teams nutzen das bis heute als Faustregel.
9. Mit Stakeholdern reviewen. Zeigen Sie, was fertig ist, sammeln Sie Feedback und aktualisieren Sie das Product Backlog.
10. Verbessern. Halten Sie die Retrospektive ab, wählen Sie ein oder zwei Maßnahmen und nehmen Sie sie in den nächsten Sprint mit, der sofort beginnt.

Eine fertige Vorlage für die Sprint-Planung bietet Ihnen Platz für Sprint-Ziel, Kapazität, ausgewählte Einträge und Aufgaben.

Beispiel: ein zweiwöchiger Sprint, Tag für Tag

So könnte ein typischer zweiwöchiger Sprint für ein sechsköpfiges Produktteam aussehen, das von Montag bis Freitag arbeitet. Die Zeiten dienen der Veranschaulichung; passen Sie sie an Ihren eigenen Kalender an.

Beispiele für Sprint-Ziele

• Softwareprodukt: „Neue Nutzer können sich mit einer geschäftlichen E-Mail-Adresse registrieren und einen Kollegen einladen, damit wir die Onboarding-Beta starten können.“
• Marketingteam: „Die Landingpage und den Anmeldeprozess für das Webinar veröffentlichen, damit wir die Anmeldung für das Event im Juni öffnen können.“
• HR-Team: „Die neue Onboarding-Checkliste mit den beiden neuen Mitarbeitenden pilotieren, die diesen Monat anfangen.“
• Interne IT: „Das Finanzteam auf das neue Laptop-Image umstellen, ohne dass der Zugriff auf gemeinsame Laufwerke verloren geht.“

Kann man einen Sprint ändern, verlängern oder abbrechen?

Der Scrum Guide gibt klare Regeln für einen laufenden Sprint vor:

• Keine Änderungen, die das Sprint-Ziel gefährden. Neue dringende Arbeit kann besprochen werden, doch das Team schützt das Ziel.
• Die Qualität nimmt nicht ab. Die Definition of Done wird nicht aufgeweicht, um einen Termin zu halten.
• Der Umfang kann geklärt und neu verhandelt werden, und zwar mit dem Product Owner, während das Team dazulernt. Einträge können getauscht oder gestrichen werden, solange das Ziel bestehen bleibt.
• Das Product Backlog wird bei Bedarf verfeinert.

Ein Sprint darf nicht verlängert werden. Die Timebox ist fest. Arbeit, die nicht fertig (Done) ist, geht zurück ins Product Backlog, wo der Product Owner sie neu einordnet; sie wird nicht automatisch in den nächsten Sprint übernommen, und halbfertige Arbeit zählt nicht zur Velocity.

Ein Sprint-Abbruch ist möglich, aber selten. Nur der Product Owner kann ihn vornehmen, und nur, wenn das Sprint-Ziel hinfällig wird, etwa weil das Unternehmen die Richtung ändert oder sich der Markt verschiebt. Bereits fertige Arbeit wird überprüft, und unvollständige Einträge gehen zurück ins Product Backlog.

Wenn Stakeholder ständig neue Arbeit in laufende Sprints drücken, behandeln Sie das als eine Form von Scope Creep: Leiten Sie Anfragen stattdessen über den Product Owner und das Product Backlog.

So verfolgen Sie den Fortschritt während eines Sprints

Sie brauchen kein aufwendiges Reporting, um einen Sprint zu steuern, aber Sie müssen sehen können, ob das Ziel auf Kurs ist.

• Scrum- oder Kanban-Board. Spalten wie To Do, In Arbeit, Review und Done zeigen die Arbeit auf einen Blick und machen Engpässe sichtbar.
• Sprint-Burndown-Chart. Stellt die verbleibende Arbeit jedes Tages einer Ideallinie gegenüber. Eine mehrere Tage flache Linie ist ein Frühwarnsignal.
• Check des Sprint-Ziels. Fragen Sie in jedem Daily Scrum, ob das Ziel noch erreichbar ist; das ist wichtiger als jedes Diagramm.
• Velocity oder Durchsatz (nach dem Sprint). Die pro Sprint fertiggestellte Arbeitsmenge, die zur Planung künftiger Sprints dient. Siehe Agile-Velocity-Charts.
• Erfolgsquote beim Sprint-Ziel. Wie oft das Team sein Ziel über mehrere Sprints erreicht hat, ist ein nützliches Maß für die Vorhersagbarkeit.

Was auch immer Sie verfolgen: Nutzen Sie es, um dem Team bei der Anpassung zu helfen, nicht um Teams oder Einzelpersonen zu vergleichen.

Vorteile der Arbeit in Sprints

• Schnelles Feedback. Stakeholder sehen alle paar Wochen funktionierende Ergebnisse statt erst am Projektende.
• Fokus. Ein einziges Ziel und ein kurzer Horizont verringern Multitasking und Kontextwechsel.
• Geringeres Risiko. Probleme zeigen sich innerhalb eines Sprints, wenn ihre Behebung noch günstiger ist.
• Vorhersagbarkeit. Ein gleichmäßiger Takt erleichtert Prognosen und die Release-Planung.
• Eingebaute Verbesserung. Die Retrospektive gibt dem Team eine regelmäßige, geschützte Zeit, um seine Arbeitsweise zu verbessern.
• Transparenz. Ziele, Backlogs und Boards machen den Fortschritt für alle sichtbar.

Häufige Sprint-Fehler und wie Sie sie beheben

Arbeiten alle agilen Teams mit Sprints?

Nein. Sprints gehören zu Scrum und zu iterationsbasierten Methoden wie XP und SAFe. Andere Ansätze funktionieren anders:

• Kanban arbeitet mit kontinuierlichem Fluss und WIP-Limits statt mit festen Sprints; Planung und Releases erfolgen bei Bedarf. Einen Vergleich finden Sie unter Kanban vs. Scrum.
• Scrumban kombiniert beides und behält oft einen Planungstakt bei, während die Arbeit als Fluss gesteuert wird.
• Design Sprints sind etwas anderes: ein strukturierter Workshop von etwa fünf Tagen (bekannt gemacht durch Google Ventures), um ein Produktkonzept zu erkunden und zu testen. Sie teilen den Namen, aber nicht die Scrum-Regeln.

Einen Vergleich dieser Ansätze finden Sie in agile Methoden im Überblick.

Sprint-Vorlagen und -Tools

Sie können Sprints mit Haftnotizen und einem Whiteboard durchführen, doch Vorlagen und Software erleichtern das Teilen der Arbeit, besonders für Remote-Teams.

• Sprint-Planning-Vorlage: Sprint-Ziel, Kapazität, ausgewählte Einträge, Schätzungen und Aufgaben.
• Vorlage für die Sprint-Retrospektive: was gut lief, was verbessert werden soll, und Maßnahmen.
• Vorlage für das Product Backlog: eine geordnete Liste von Einträgen, bereit für künftige Sprints.
• Vorlage für User Stories: einheitliche Stories mit Akzeptanzkriterien und Schätzungen.
• Vorlage für agile Projektpläne: Releases, Sprints und Meilensteine in einer Ansicht.

Die meisten Projektmanagement-Tools unterstützen inzwischen Sprints. Jira ist auf Scrum- und Kanban-Boards für Softwareteams ausgerichtet, während Wrike, unser insgesamt bestbewertetes Tool, zu Teams passt, die Sprints abteilungsübergreifend neben anderen Arten von Arbeit durchführen.

Kostenlose Vorlagen zu diesem Thema

Alle Vorlagen ansehen

Häufig gestellte Fragen