Scrum Sprint

Merkmale von Scrum Sprints

Folgende Merkmale definieren einen Sprint:

• Alle Arbeiten, die zur Erreichung des Produktziels erforderlich sind, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospektive, finden im Rahmen von Sprints statt. Damit ist der Sprint praktisch ein Container für die anderen 4 Events.
• Jeder Scrum Sprint beginnt mit dem Sprint Planning. Dort wird das Sprint-Ziel definiert und festgelegt, welche Product Backlog Items in das Sprint Backlog aufgenommen und im Sprint realisiert werden. Im Anschluss committed sich das Scrum Team auf das Sprint-Ziel.
• Das Ergebnis des Sprints ist ein potentiell auslieferbares Inkrement – auch als Increment of Potentially Shippable Functionality bezeichnet. Theoretisch sind auch mehrere Auslieferungen pro Sprint denkbar, verpflichtend ist nur ein Inkrement zum Sprint-Ende.
• Ein Sprint hat immer eine gleichbleibende Dauer – auch als Timebox bezeichnet. Laut Scrum Guide bewegt sich die Dauer von einer Woche bis maximal einen Monat. Dieser relativ kurze Zeitraum ist ein wesentlicher Unterschied zur klassischen Iteration, die keine standardisierte Vorgabe zur Dauer definiert. Auch der Begriff als solches deutet an, dass es sich im übertragenen Sinne nicht um einen Mittelstrecken- oder Langstreckenlauf sondern um eine Kurzstrecke – einen Sprint – handelt. Bei längeren Strecken könnte die Komplexität und damit das Risiko von Fehlentwicklungen steigen. Sprints fördern die Vorhersehbarkeit, indem sie mindestens die kontinuierliche Überprüfung und Anpassung des Fortschritts in Richtung des Ziels sicherstellen. Gleichzeitig wird auch das finanzielle Kostenrisiko auf die Dauer des Sprints begrenzt.
• An jedem Arbeitstag treffen sich die Entwickler (und ggf. der Scrum Master und der Product Owner) zum Daily Scrum und tauschen sich über die erledigten und anstehenden Aufgaben zur Erreichung des Ziels, sowie mögliche Hindernisse bei der Arbeit aus. Den Status der Aufgaben wird oftmals per Taskboard visualisiert.
• Zum Ende des Scrum Sprints wird ein Review durchgeführt, in dem das Team wichtigen Stakeholdern (und als Stellvertreter der Stakeholder dem Product Owner) die fertiggestellten Arbeitsergebnisse präsentiert.
• Nach dem Review wird eine Retrospektive durchgeführt. Dort reflektieren das Scrum Team den letzten Sprint und schaut,  welche Aspekte es im nächsten Zeitintervall beibehalten und welche weggelassen werden sollten.

Regeln bei Scrum Sprints

Darüber hinaus sollten folgende Regeln bzw. Punkte beachtet werden:

• Während eines Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden könnten.
• Qualitätsziele werden nicht reduziert.
• Der Scope kann zwischen Product Owner und den Entwicklern verhandelt werden, sobald neue Erkenntnisse und Lessons Learned vorliegen.
• Der Product Owner ist derjenige, der einen Sprint abbrechen könnte, sollte sich das vereinbarte Ziel als überholt darstellen.
• Die Entwickler beseitigen idealerweise selbständig mögliche Impediments. Dies ist ein Schritt in Richtung Selbstmanagement. Der Scrum Master hilft nur bei Bedarf.
• Das Burn-Down-Chart oder alternativ das Burn-Up-Chart sind Tools, um den Fortschritt innerhalb eines Sprints zu visualisieren.
• Die Geschwindigkeit des Entwicklungsteams pro Sprint wird als Velocity bezeichnet. Es ist allerdings nicht das Ziel in Scrum, die Velocity zu steigern, sondern durch die Velocity eine Hilfe für künftige Sprint Plannings zu erhalten.
• Ein neuer Sprint beginnt unmittelbar nach Abschluss des vorherigen Sprints.

Sprint Dauer

Wer bestimmt die Dauer der Scrum Sprints? Idealerweise alle Beteiligten gemeinsam, also die Entwickler, der Scrum Master und der Product Owner. Doch was passiert, wenn die Meinungen über die Dauer auseinander gehen – wer sollte dann entscheiden? Hier variieren die Meinungen:

• Der Product Owner ist prädestiniert die Dauer festzulegen, da er die Kunden und Anwender “kennt” und weiß, in welcher Frequenz diese neue Inkremente erwarten. In der Praxis kommt es jedoch häufig vor, dass Lieferungen in einem wöchentlichen oder monatlichen Rhythmus Organisationen überfordern; das Inkrement am Ende des Sprints muss nicht ausgeliefert werden, sondern soll lediglich “lieferbar” sein. Daraus ergibt sich: erwartet der Kunde in kurzen Zyklen neue Inkremente, dann könnte der Product Owner die Dauer festlegen.
• Der Scrum Master ist prädestiniert die Dauer festzulegen, denn er kennt idealerweise die Entwickler und dessen Fähigkeit am besten, einen lieferbaren Mehrwert zu erzeugen. Es nützt nichts, wenn der Product Owner im Sinne des Geschäfts eine Dauer definiert, das Team dies aber nicht leisten kann. Möglicherweise gibt es auch technische Zusammenhänge und Notwendigkeiten, die Einfluss auf eine passende Dauer haben.

Letztendlich läuft es also auf die Frage hinaus: was möchte der Markt bzw. der Kunde und was kann das Team dauerhaft in entsprechender Qualität entwickeln? Die Antwort auf diese Frage muss jede Organisation für sich finden.

Benennung von Sprints

Es gibt verschiedene Möglichkeiten Sprints zu benennen. In der Praxis zeigt sich immer wieder, dass ein gewisses Maß an Kreativität zur Stärkung des Teams bzw. zur Teambildung beiträgt:

• Üblicherweise werden Scrum Sprints mit Nummern versehen, beginnend bei Sprint 0, dann 1,  2, usw.
• Die Benennung kann auch mit Film- oder Songtiteln erfolgen. Wichtig wäre in einem solchen Fall lediglich, dass z.B. der Filmtitel zum  vereinbarten Ziel passt und nicht das Ziel passend zum Filmtitel ausgewählt wird.
• Alternativ lassen sich auch Biermarken, Künstler, Charakteren aus Computerspielen oder Tiere als Namensgeber nutzen.

Erlaubt ist, was gefällt.

Verwendung von unterschiedlichen Sprint Metriken

In vielen Unternehmen wird die Velocity bzw. der Velocity-Faktor als Maßeinheit für die Planung von Sprints basierend auf Story Points genutzt. Darüber hinaus gibt es zahlreiche weitere agile Metriken, die zum Einsatz kommen könnten:

👥 Anwesenheitsquote: der Prozentsatz der Teammitglieder, die an täglichen Besprechungen oder anderen Teamveranstaltungen teilnehmen.

📉 Backlog Health: ein Maß für den allgemeinen Zustand und die Effizienz des Backlogs des Teams, einschließlich Faktoren wie Backlog-Größe, veraltete Elemente und Fortschritte bei der Fertigstellung.

♻️ Cycle Time: die Zeit, die ein Team benötigt, um eine Aufgabe von Anfang bis Ende zu erledigen.

📌 Escaped Defects: Die Anzahl der Fehler, die trotz der Bemühungen des Teams, sie zu vermeiden, in das Endprodukt gelangen.

💥 Fehlerdichte: die Anzahl der Fehler pro Arbeitseinheit.

📈 Flow-Efficiency: der Prozentsatz der Zeit, in der ein Team tatsächlich an der Wertschöpfung arbeitet, anstatt auf Ressourcen oder Genehmigungen zu warten.

👏 Kundenzufriedenheit: ein Maß dafür, wie zufrieden die Kunden mit der Arbeit des Teams sind.

🕖 Lead Time: die Zeit, die von der Anforderung einer Aufgabe durch einen Kunden bis zur Lieferung der Aufgabe vergeht.

🔨 Mean Time To Repair (MTTR): die durchschnittliche Zeit, die für die Reparatur eines Fehlers benötigt wird.

❓ Prozentsatz der Nacharbeit: der Prozentsatz der Arbeit, die aufgrund von Mängeln oder anderen Problemen nachgearbeitet wird.

💪 Team-Moral: ein allgemeines Maß für das Engagement und die Motivation des Teams, das durch Umfragen oder andere Formen des Feedbacks ermittelt wird.

🕧 Time to Market: Die Zeit, die ein Team benötigt, um ein Produkt oder eine Funktion auf den Markt zu bringen.

🕝 Time to Value: Die Zeit, die ein Team benötigt, um dem Kunden einen greifbaren Wert zu liefern.

📊 Work in Progress (WIP): Die Menge der Arbeit, die derzeit im System in Bearbeitung ist. Diese Kennzahl kann Teams helfen, Engpässe zu erkennen und Multitasking zu reduzieren, insbesondere in Kombination mit dem WIP Limit als maximale Anzahl von Aufgaben, an denen ein Team zu einem bestimmten Zeitpunkt arbeiten kann.

Sicherlich lässt sich diese Liste ergänzen. Der Scrum Guide definiert keine agile Metrik; Organisationen können sich also entscheiden, welche Metrik oder auch welche Metriken für ihre Arbeit am nützlichsten ist bzw. sind.

Impulse zum Diskutieren:

Ist die Länge des Zeitintervalls auch immer ein Kompromiss zwischen “schnell auf Veränderungen reagieren müssen” und “in Ruhe arbeiten können”?

Können Sie sich Situationen vorstellen, in denen sogenannte “nested” – also verschachtelte – Sprints sinnvoll sein können?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

Jeff Sutherland hat in seinem Buch “Scrum: The Art of Doing Twice the Work in Half the Time” erläutert, wie die  Bezeichnung Sprint entstand: “… And so my team embarked on what we called ‘Sprint’. We called them because the name evoked a quality of intensitiy. We were goint to work all out for a short period of time and then stop to see where we were”. Frei ins Deutsche übersetzt: “… Und so begann mein Team mit dem, was wir ‘Sprint’ nannten. Wir nannten sie so, weil der Name eine gewisse Intensität suggerierte. Wir wollten für eine kurze Zeit alles geben und dann innehalten, um zu sehen, wo wir stehen”.

Hier finden Sie einen Podcast zum Thema: Die passende Sprintlänge finden. Ein Gespräch von Ralf Krause und Dominik Ehrenberg.

Und hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.