0 0 Votes
Artikel-Rating

Warum heißen Sprints eigentlich Sprints?

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.

And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were.

Jeff SutherlandJeff Sutherland, Scrum Inc.

Sprints sind “Iterationen”

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:

  • Sprint Planning

  • Daily Scrum

  • Sprint Review

  • Sprint Retrospektive

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

Scrum-Sprint-Hotspot-Image.png
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospektive
Scrum-Sprint-Hotspot-Image.png
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospektive

Die 4 Scrum Events eines Sprints

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

Sprint Planning

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.

Scrum-Sprint-Hotspot-Image.png
Sprint Planning
Scrum-Sprint-Hotspot-Image.png
Sprint Planning

Kurzinfos zum Sprint Planning

  • Teilnehmer: Das gesamte Scrum Team (Product Owner, Scrum Master & Entwickler) plus eventuell eingeladene Kollegen

  • Timebox: Maximal 8 Stunden (bei einem einmonatigen Sprint)

  • Sinn & Zweck: Formulierung eines Sprintziels und Erstellung eines gemeinsamen Plans (Beides wird im Sprint Backlog festgehalten)

Daily Scrum

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 Increment 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.

Scrum-Sprint-Hotspot-Image.png
Daily Scrum
Scrum-Sprint-Hotspot-Image.png
Daily Scrum

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.

  • Ausführlichere Information zum Daily findest Du in meinem Beitrag Was ist ein Daily Scrum?, falls Du hier tiefer einsteigen möchtest.

Kurzinfos zum Daily Scrum

  • Teilnehmer: Die Entwickler des Scrum Teams

  • Timebox: Maximal 15 Minuten

  • Sinn & Zweck: Transparenz über den aktuellen Stand der Arbeit herstellen und darüber, ob das Sprintziel (noch) erreicht werden kann.

Sprint Review

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.

Scrum-Sprint-Hotspot-Image.png
Sprint Review
Scrum-Sprint-Hotspot-Image.png
Sprint Review

Kurzinfos zur Sprint Review

  • Teilnehmer: Scrum Team und (vom Product Owner) eingeladene Stakeholder

  • Timebox: Maximal 4 Stunden (bei einem einmonatigen Sprint)

  • Sinn & Zweck: Überprüfung des neuen Increments und Anpassung des Product Backlogs

Sprint Retrospektive

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.

Scrum-Sprint-Hotspot-Image.png
Sprint Retrospektive
Scrum-Sprint-Hotspot-Image.png
Sprint Retrospektive

Kurzinfos zur Sprint Review

  • Teilnehmer: Scrum Team

  • Timebox: Maximal 3 Stunden (bei einem einmonatigen Sprint)

  • Sinn & Zweck: Verbesserung der Teamzusammenarbeit und -effektivität

Wie lange dauert ein Sprint in Scrum?

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.

Veränderte Timeboxen der Scrum Events

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.

Nach dem Sprint ist vor dem Sprint

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.

Vorteile von Scrum-Sprints

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

  • Sprints erzeugen einen gleichbleibenden Arbeitsrhythmus.

  • Wert & Nutzen wird kontinuierlich an Nutzer und Kunden ausgeliefert.

  • Das Risiko, ein Produkt in die falsche Richtung zu entwickeln, wird minimiert.

Sprints erzeugen einen Rhythmus

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.

  • Bei den meisten agilen Teams haben sich Story Points etabliert, mit deren Hilfe sich eine Team-Velocity berechnen lässt. Story Points und Velocity unterstützen Euch dabei, Aufwände zu schätzen und Euren Sprint zu planen.

Kontinuierliche Lieferung von Wert

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.

Sprints reduzieren Risiko

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.

Sprint-Abbruch

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.

Fazit zu Sprints

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!