Sprint
Definition
Ein Sprint ist eine kurze, zeitlich festgelegte Timebox (in der Regel 1 bis 4 Wochen), in der ein Scrum-Team ein verwendbares und potenziell auslieferbares Inkrement eines funktionierenden Produkts erstellt. Jeder Sprint beginnt unmittelbar nach dem vorherigen und bildet so einen kontinuierlichen Entwicklungszyklus. Der Sprint umfasst alle Scrum-Ereignisse: Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive.
Warum es wichtig ist
Sprints bringen Rhythmus, Fokus und Struktur in die komplexe Produktentwicklung. Diese konsistente Taktung sorgt für Vorhersehbarkeit sowohl im Team als auch bei Stakeholdern und erleichtert so Planung und Koordination. Sie ermöglichen häufige Inspektionen des Fortschritts sowie Anpassungen basierend auf Feedback und helfen dem Team, effektiv auf Veränderungen zu reagieren. Dieser iterative und inkrementelle Ansatz verkörpert Empirie, indem das Team aus realen Ergebnissen lernt und sich anpasst. Durch die Verpflichtung zu einem Sprint-Ziel richtet das Team seine Anstrengungen auf ein gemeinsames Ziel aus und fördert Transparenz und Stakeholder-Vertrauen.
Sprints begrenzen Risiken auf einen kurzen Zeitraum und fördern kontinuierliches Lernen durch regelmäßige Retrospektiven. Dieses inkrementelle Liefermodell unterstützt Agilität und stellt sicher, dass das Team kontinuierlich auf die Lieferung von Kundenwert hinarbeitet.
Wann & wie es verwendet wird
Ein Scrum-Team nutzt Sprints als zentralen Lieferzyklus. Jeder Sprint beginnt mit dem Sprint Planning, bei dem das Team Product Backlog Items auswählt und sich auf ein Sprint-Ziel einigt. Daily Scrums helfen dabei, den Fortschritt zu inspizieren und das Sprint Backlog bei Bedarf anzupassen. Der Sprint selbst ist ein Container für alle Arbeiten, die notwendig sind, um das Sprint-Ziel zu erreichen – einschließlich Design, Entwicklung, Test und Dokumentation.
Am Ende des Sprints findet ein Sprint Review mit den Stakeholdern statt, um das Inkrement zu inspizieren und Feedback zu sammeln. Darauf folgt die Sprint Retrospektive, in der das Team reflektiert, wie es gearbeitet hat, und Verbesserungen für den nächsten Sprint identifiziert. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden; wird das Sprint-Ziel jedoch obsolet oder unerreichbar, kann der Product Owner den Sprint in Ausnahmefällen abbrechen.
Beispiel aus der Praxis
Ein Softwareentwicklungsteam, das an einer E-Commerce-Website arbeitet, organisiert sich in zweiwöchigen Sprints. Im Sprint Planning beschließen sie, den Checkout-Prozess als Sprint-Ziel umzusetzen. Während des Sprints integrieren sie den Warenkorb, binden das Zahlungssystem ein und erstellen die Bestätigungsseite. Im Sprint Review präsentieren sie einen funktionierenden Checkout-Flow und erhalten Feedback zur Verbesserung der Bestätigungs-E-Mail. Dieses unmittelbare Feedback ermöglicht es dem Team, das Produkt in den nächsten Sprints gezielt weiterzuentwickeln. In der Retrospektive stellt das Team fest, dass eine bessere funktionsübergreifende Zusammenarbeit die Testgeschwindigkeit erhöhen könnte.
Häufige Fallstricke oder Missverständnisse
- Häufige Änderungen der Sprint-Länge: Teams verlieren die Fähigkeit zur Prognose und zur effektiven Messung der Velocity, und es wird der etablierte Rhythmus gestört, was es dem Team erschwert, ein nachhaltiges Tempo zu finden und aus Prozessen zu lernen.
- Kein klares Sprint-Ziel: Ohne ein gemeinsames Ziel fehlt dem Team der Fokus und die Zielgerichtetheit, was den gelieferten Wert verringert.
- Sprints als Mini-Wasserfälle nutzen: Wenn Design, Entwicklung und Test streng nacheinander im Sprint stattfinden, wird Agilität untergraben – kontinuierliche Integration und Feedback-Schleifen werden verhindert. Arbeit sollte innerhalb des Sprints fließen und regelmäßig integriert und getestet werden.
- Neue Arbeit spät im Sprint beginnen: Dies führt häufig zu unvollständiger Arbeit und reduziert die Qualität des Inkrements.
- Kein „Done“-Inkrement liefern: Wird am Ende des Sprints kein verwendbares und potenziell auslieferbares Ergebnis erreicht, wird der zentrale Zweck des Sprints (Wertschöpfung) verfehlt – und technische Schulden können schnell entstehen.