Der Sprint

Sprints sind Ereignisse von fester Länge von einem Monat oder weniger, um eine konsistente Liefer- und Feedback-Kadenz für das Scrum-Team zu schaffen. Je kürzer die Sprintlänge, desto schneller die Feedbackschleife. Scrum Inc. arbeitet zum Beispiel in einwöchigen Sprints.

Der Sprint ist ein Container für alle anderen Ereignisse. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints, und jeder Sprint beginnt typischerweise mit dem Sprint Planning und endet mit dem Sprint Review & Sprint Retrospective. An jedem Tag des Sprints gibt es ein kurzes Ereignis, das Daily Scrum, das dazu dient, das Team auszurichten und Hindernisse aufzudecken, auf die das Team stößt, um Fortschritte im Sprint Backlog zu erzielen. Alle Arbeiten und Ereignisse, die notwendig sind, um das Sprint Goal zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb von Sprints statt.

Der regelmäßige Sprint-Zyklus dient dazu:

• Die Lieferung auf das Sprint Goal zu konzentrieren. In jedem Sprint sollte das Team ein potenziell auslieferbares Software-Inkrement, eine brauchbare Iteration eines Hardware-Produkts oder letztlich: einen eindeutigen Kundennutzen entwickeln.
• Das Team erhält regelmäßiges, qualitativ hochwertiges Kundenfeedback zum gelieferten Wert. Das Team kann dann sowohl seinen Prozess als auch sein Produkt auf der Grundlage echter und umsetzbarer Kundenbeiträge überprüfen und anpassen.
• Messen Sie den Output des Teams über einen konsistenten und wiederkehrenden Zeitraum. Diese Messung des Outputs wird als „Velocity“ des Teams bezeichnet. Mit Hilfe der Velocity kann das Team seine Fähigkeit, Arbeit im Laufe der Zeit zu liefern, vorhersagen und realistische Sprint-Pläne auf der Grundlage historischer Daten erstellen.

Sprints ermöglichen Vorhersehbarkeit, indem sie mindestens jeden Kalendermonat eine Überprüfung und Anpassung des Fortschritts in Richtung des Produktziels gewährleisten. Kürzere Sprints können mehr Lernzyklen erzeugen und das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen begrenzen. Wenn der Horizont eines Sprints zu lang ist, kann das Sprint Goal ungültig werden, die Komplexität kann steigen und das Risiko kann zunehmen. Jeder Sprint kann als Kurzprojekt betrachtet und abgebrochen werden, wenn das Sprint Goal veraltet ist. Nur der Product Owner hat die Befugnis, den Sprint abzubrechen.