Sprint

Inkrementelle Entwicklung in kurzen Zyklen: Der Scrum Sprint

Scrum ist ein Framework, das die Entwicklung von Software, Produkten und Dienstleistungen unterstützt. Es verfolgt einen inkrementellen, iterativen und empirischen Ansatz und besteht aus wenigen Verantwortlichkeiten, Artefakten und fünf wichtigen Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive. Der Sprint bildet dabei das Herzstück von Scrum, oft als „Herzschlag von Scrum“ bezeichnet. Es handelt sich um eine zeitlich festgelegte Iteration mit konstanter Dauer und immer ähnlichen Abläufen, die auf die Umsetzung einer definierten Lösung abzielt.

Eigenschaften von Scrum Sprints

Ein Sprint umfasst alle Arbeiten, die zur Erreichung des Produktziels nötig sind, einschließlich der Events Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospektive. Der Sprint fungiert somit als Rahmen für die anderen vier Events. Er beginnt mit der Sprint Planung, in der das Sprint-Ziel festgelegt und entschieden wird, welche Product Backlog Items ins Sprint Backlog aufgenommen werden. Das Team verpflichtet sich anschließend auf das Sprint-Ziel. Das Ergebnis ist ein potentiell lieferbares Inkrement, wobei mehrere Auslieferungen innerhalb eines Sprints möglich sind. Ein Sprint besitzt eine festgelegte Dauer, auch als Timebox bezeichnet, die zwischen einer Woche und einem Monat liegt. Diese kurze Zeitspanne unterscheidet sich von der klassischen Iteration und hilft, Komplexität und Risiken zu minimieren. Sprints fördern Vorhersagbarkeit durch regelmäßige Überprüfung und Anpassung des Fortschritts sowie die Begrenzung des finanziellen Risikos auf die Sprint-Dauer.

Täglich treffen sich die Entwickler (und ggf. der Scrum Master und der Product Owner) zum Daily Scrum, um über erledigte und anstehende Aufgaben sowie Hindernisse zu sprechen. Der Fortschritt wird oft über ein Taskboard visualisiert. Am Ende des Sprints findet ein Review statt, bei dem das Team die Ergebnisse wichtigen Stakeholdern präsentiert. Anschließend reflektiert das Team in einer Retrospektive über den letzten Sprint und entscheidet, welche Aspekte beibehalten oder verändert werden sollten.

Regeln für Scrum Sprints

Es gibt bestimmte Regeln, die während eines Sprints beachtet werden müssen: Änderungen, die das Sprint-Ziel gefährden könnten, sind nicht gestattet. Qualitätsziele dürfen nicht gesenkt werden. Der Umfang kann zwischen Product Owner und Entwicklern angepasst werden, sobald neue Erkenntnisse vorliegen. Der Product Owner kann einen Sprint abbrechen, wenn das Ziel überholt ist. Die Entwickler sollten idealerweise selbstständig Hindernisse beseitigen, wobei der Scrum Master bei Bedarf unterstützt. Fortschritte werden oft durch ein Burn-Down- oder Burn-Up-Chart visualisiert. Die Geschwindigkeit des Teams pro Sprint, bekannt als Velocity, dient zur Unterstützung künftiger Sprint Planungen.

Ein neuer Sprint beginnt unmittelbar nach Abschluss des vorherigen. Die Dauer der Sprints wird idealerweise gemeinsam von allen Beteiligten festgelegt. Sollte es Meinungsverschiedenheiten geben, könnte der Product Owner aufgrund seiner Nähe zu den Kunden oder der Scrum Master aufgrund seines Wissens über die Teamfähigkeiten die Dauer bestimmen. Letztlich hängt es davon ab, welche Frequenz der Markt erwartet und was das Team leisten kann.

Benennung von Sprints

Sprints können kreativ benannt werden, um das Team zu stärken. Üblicherweise werden sie numerisch benannt, beginnend bei Sprint 0. Alternativ können auch Film- oder Songtitel, Biermarken, Künstler oder Tiere als Namensgeber genutzt werden.

Verwendung von verschiedenen Sprint Metriken

Viele Unternehmen verwenden die Velocity zur Planung von Sprints basierend auf Story Points. Es gibt jedoch zahlreiche weitere agile Metriken, die genutzt werden könnten, wie Anwesenheitsquote, Backlog Health, Cycle Time, Escaped Defects, Fehlerdichte, Flow-Efficiency, Kundenzufriedenheit, Lead Time, Mean Time To Repair (MTTR), Prozentsatz der Nacharbeit, Team-Moral, Time to Market, Time to Value und Work in Progress (WIP). Der Scrum Guide definiert keine festen Metriken, sodass Organisationen selbst wählen können, welche für sie am nützlichsten sind.