Was ist ein Sprint?

Sprints sind der Herzschlag des Scrum Frameworks. In diesem Artikel erkläre ich Dir, wie Sprints aufgebaut sind, warum sie auch Iteration heißen und was ihre großen Vorteile sind.

Die Bezeichnung Sprint entstand während Jeff Sutherlands gemeinsamer Arbeit mit einem Scrum Team, um die Intensität durch fokussierte Umsetzung von Software zu verdeutlichen. (Und wohl auch, um den Kontrast zu den damals üblichen Entwicklungs-Marathons hervorzuheben.)

Ein Scrum Team sprintet eine kurze Strecke, stellt eine neue Funktion fertig, hält danach inne und betrachtet den zurückliegenden Zeitraum, um für den nächsten Sprint Kurskorrekturen und Verbesserungen vorzunehmen.

Falls Du neu in Scrum bist, ist Dir vielleicht schon das Wort Iteration begegnet. Eine Iteration meint nichts anderes als einen Prozess, der immer in der gleichen Abfolge wiederholt wird. Dahinter steckt also gar nichts Kompliziertes.

Wenn Du schon einmal ein Brettspiel gespielt hast, kennst Du auch bereits Iterationen. (Nur wusstest wahrscheinlich nicht, dass es Iterationen sind.) Denn jeder Spielzug eines Brettspielst ist nichts anderes als eine Iteration.

Beim Spiel Carcassonne ist der Spielzug beispielsweise:

1. Der Spieler muss 1 neue Landschaftskarte ziehen und anlegen.
2. Der Spieler kann 1 eigenen Gefolgsmann aus seinem Vorrat auf die soeben gelegte Karte setzen.
3. Sind durch das Anlegen der Karte fertige Straßen, Städte oder Klöster entstanden, müssen sie jetzt gewertet werden.

Sprints in Scrum sind ebenfalls Iterationen und bestehen aus der fest definierten Abfolge von vier Scrum Events. Ist der Sprint beendet, beginnt sofort der nächste.

Damit stellt der Sprint als Scrum Event gewissermaßen einen Sonderfall dar. Denn im Gegensatz zu den vier anderen Scrum Events dient er nicht der Überprüfung & Anpassung, sondern ist lediglich eine Art Container für die übrigen vier Scrum Events.

Die vier Scrum Events eines Sprints sind:

Weil sich diese Abfolge immer gleich wiederholt, hat es sich eingebürgert, Sprints als Kreislauf darzustellen.

Gehen wir ein wenig auf die einzelnen Scrum Events innerhalb eines Sprints genauer ein und schauen, welchen Sinn und Zweck sie haben.

Jeder Sprint in Scrum beginnt mit dem sogenannten Sprint Planning. Bei diesem Scrum Event trifft sich Euer Team und einigt sich gemeinsam auf ein Sprintziel, das Ihr im kommenden Sprint erreichen möchtet. Zweitens entscheidet Ihr, was dafür getan werden muss, um das Sprintziel zu erreichen und drittens entwerft Ihr gemeinsam einen Plan, wie es erreicht werden kann.

All diese Informationen, Aufgaben und ToDo’s haltet Ihr abschließend in Eurem Sprint Backlog fest, mit dem die Entwickler Eures Scrum Teams im kommenden Sprint arbeiten werden.

Nachdem das Sprint Planning abgeschlossen ist, beginnt der eigentliche Sprint und die Entwickler Eures Scrum Teams machen sich daran, bis zum Ende Eurer Iteration ein nutzbares Inkrement abzuliefern. Damit währenddessen ausreichend Transparenz darüber herrscht, wie es um die Erreichung des Sprintziels steht, treffen sich die Entwickler einmal täglich zum Daily Scrum.

Das Daily Scrum ist ein kurzes, 15-minutiges Treffen, in dem jeder Entwickler seinen Kollegen ein kurzes Update darüber gibt, wie er mit seiner Arbeit vorankommt.

Dies geschieht vor allem mit Hilfe des Sprint Backlogs, das spätestens kurz vor dem Daily Scrum auf dem aktuellen Stand sein sollte.

Potenzielle Probleme oder Impediments werden hier lediglich kurz angesprochen, jedoch nicht gelöst oder diskutiert, um das Meeting kurz zu halten.

Stoßen die Entwickler auf Herausforderungen, die sie nicht selbst lösen können, können sie diese an ihren Scrum Master abgeben oder zu Rate ziehen.

Das Ende eines Sprints beginnt mit der Sprint Review. Zu diesem kollaborativen Workshop lädt Dein Team seine wichtigsten Stakeholder ein, um ihnen die neuen Funktionen Eures Produktes zu präsentieren. Auf Basis des daraus resultierenden Feedbacks wird Euer Product Backlog aktualisiert, erweitert oder seine Priorisierung verändert.

Der Sinn & Zweck der Sprint Review ist es also, auf Basis der neuen Ergebnisse eventuelle Kurskorrekturen abzuleiten.

Nach der Sprint Review folgt die Sprint Retrospektive. In diesem letzten Scrum Event wirft Dein Team einen Blick auf die zurückliegende Iteration und überlegt gemeinsam, wie es durch (kleine) Veränderungen im nächsten Sprint noch besser werden kann. Im Fokus dieses Workshops stehen dabei Individuen, Interaktionen, Prozesse & Tools.

Darüber hinaus ist die Sprint Retrospektive der formale Ort, an dem Ihr Eure Definition of Done verändern könnt, um die Qualität Eures Produktes weiter zu verbessern.

Ein Sprint darf laut Scrum Guide maximal einen Kalendermonat dauern. Das liegt hauptsächlich daran, dass größere Zeiträume aufgrund der hohen Komplexität in der Produktentwicklung nicht ausreichend gut genug planbar sind.

Die meisten Scrum Teams nutzen einen Zeitraum von zwei Wochen.

Aber auch eine Woche ist denkbar, wenn Euer Team mit vielen Veränderungen konfrontiert sein sollte.

Die Länge eines Sprints sollte immer gleich bleiben und nur in Ausnahmefällen verändert werden. Denn das hilft Dir und Deinem Team dabei, einen gleichbleibenden Arbeitsrhythmus zu etablieren.

Die Dauer der Scrum Events (Timebox) verkürzt sich entsprechend, wenn Euer Sprint weniger als einen Monat dauert.

Bei einer zweiwöchigen Iteration darf das Sprint Planning maximal 4 Stunden (statt 8), die Review maximal 2 Stunden (statt 4) und Eure Retrospektive maximal 1,5 Stunden (statt 3) dauern. Die Dauer des Daily Scrums beträgt immer eine Viertelstunde, egal wie lang Euer Sprint ist.

Zwischen zwei Sprints gibt es keine Pausen oder Zeiträume, in denen Aufräumarbeiten oder dergleichen erledigt werden. Das heißt, wenn ein Sprint mit der Retrospektive abgeschlossen ist, geht Dein Scrum Team direkt über zum Sprint Planning.

Die Arbeit in Sprints bietet Euch in der Produktentwicklung oder bei der Umsetzung eines Projektes drei wichtige Vorteile.

Einer der größten Vorteile von Sprints ist der regelmäßige Rhythmus, den Iterationen erzeugen. Unabhängig davon, wie groß ein zu entwickelndes Feature oder umzusetzendes Projekt ist, wird Arbeit stets so eingeteilt, dass sie zum Ende des Sprints fertiggestellt werden kann. Das verlangt natürlich ein wenig Übung, um einschätzen zu können, wie viel ein Team pro Iteration umsetzen kann.

Zweitens kommt hinzu, dass in Scrum inkrementell gearbeitet wird. Das heißt, am Ende eines Sprints entsteht ein nutzbares Produkt, das auch in der Praxis eingesetzt werden kann (und soll). Dadurch können Eure Nutzer und Kunden kontinuierlich mit neuen Features versorgt werden, die direkt Nutzen stiften können.

Natürlich sind das nicht immer bahnbrechende neue Funktionen, sondern kleine Erweiterungen, die sich auch innerhalb eines Sprints umsetzen lassen. Aber die Kontinuität sorgt dafür, dass Nutzen permanent erweitert wird.

Drittens sorgen kurze Sprints dafür, dass sich Euer Produkt nicht in die falsche Richtung entwickelt. Weil am Ende eines Sprints eine Auslieferung stattfindet, sind Kurskorrekturen in der Produktentwicklung jederzeit möglich. Beispielsweise wenn durch den Einsatz einer neuen Funktion neue Ideen und Wünsche bei Euren Nutzern entstehen.

Auch das beste Scrum Team ist nicht davor geschützt, einen laufenden Sprint abzubrechen. Es gibt diverse Gründe, die für einen Sprint-Abbruch sprechen. Der wichtigste tritt dann ein, wenn Euer aktuelles Sprintziel keinen Sinn mehr ergibt.

Ich hoffe, ich konnte Dir die Funktionsweise von Sprints in Scrum näherbringen und Dir die Vorteile von Iterationen aufzeigen. Solltest Du noch Fragen, Idee, Anregungen oder Kritik zu diesem Artikel haben, freue ich mich wie immer über einen Kommentar hier unten auf der Seite!