Scrum im Selbststudium – Teil 11: Sprint – Erstellung eines Inkrements
Willkommen zum 11. Teil der „Scrum im Selbststudium“-Artikelreihe. Die Übersicht zu allen Teilen findest du am Ende dieses Beitrags.
In den nächsten Teilen schauen wir uns die verschiedenen Scrum Events näher an und beginnen mit dem Sprint.
„Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.“
Scrum Guide, 2020
Das Sprint-Event ist eine Timebox von fester Länge. Die Länge beträgt einen Monat oder weniger. Ein Sprint endet, wenn die Timebox erreicht ist.
Sprints schaffen somit Konsistenz, damit sich das Scrum Team uneingeschränkt darauf fokussieren kann, einen Teil eines komplexen Problems zu lösen. Wie bei einem Puzzle lösen Scrum Teams komplexe Probleme, indem sie mit einem kleinen Bereich beginnen. Diese Teillösung wird durch das Inkrement repräsentiert.
Somit ist der Zweck eines Sprints, ein neues Inkrement zu erstellen.
Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospektive, finden innerhalb der Sprints statt.
Während des Sprints
- werden keine Änderungen vorgenommen, die das Sprint‐Ziel gefährden würden,
- nimmt die Qualität nicht ab,
- wird das Product Backlog nach Bedarf verfeinert und
- kann der Umfang (Inhalt und Ausmaß) geklärt und mit dem Product Owner neu vereinbart werden, sollten mehr Erkenntnisse gewonnen werden. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints. Es gibt keinen Zeitraum zwischen zwei Sprints. Wurden Product-Backlog-Einträge in einem Sprint nicht abgeschlossen, wandern sie zurück in den Product Backlog und der Product Owner entscheidet, wie damit verfahren werden soll.
Wie gehen Scrum-Teams mit ungeplanter Arbeit um?
Einerseits benötigt das Unternehmen Flexibilität, um auf Marktänderungen schnell reagieren zu können. Andererseits benötigt das Scrum Team Stabilität, um etwas Wertstiftendes zu erstellen. Ein Sprint stellt somit einen notwendigen Kompromiss zwischen Flexibilität und Stabilität dar. Größere Richtungsänderungen des Scrum Teams sind auf die Sprintgrenzen zu beschränken. Fallen ungeplante Arbeiten für das Team an, entscheidet der Product Owner zusammen mit den Entwicklern, welche Einträge aus dem Sprint nicht mehr weiterverfolgt werden sollen, damit das Sprint-Ziel nicht gefährdet wird.
Kann ein Sprint abgebrochen werden?
Ein Sprint stellt den zentralen Planungshorizont eines Scrum Teams dar. Sprints sollten immer gleich lang sein, um für das Team und seine Stakeholder einen Rhythmus und Vorhersehbarkeit zu schaffen. Daher werden Sprints nicht abgebrochen, nur im unwahrscheinlichen Fall, dass die Erreichung des Sprint-Ziels nicht mehr sinnvoll erscheint. In dieser Situation kann der Product Owner den Sprint abbrechen.
Wie lang sollte ein Sprint sein?
Der Scrum Guide gibt keine Länge für Sprints vor, außer, dass sie weniger als einen Monat dauern sollten. Die Länge sollte so kurz wie möglich gewählt werden, aber lange genug, dass das Scrum Team ein sinnvolles Inkrement erstellen kann, welches das Sprint-Ziel erfüllt. Wenn ein Sprint zu lang wird, gehen wertvolle Gelegenheiten verloren, um Annahmen zu überprüfen und sicherzustellen, dass die Arbeit weiterhin in die richtige Richtung geht. Mit zunehmender Länge der Sprints steigt auch das Risiko, Zeit mit der Entwicklung von falschen Dingen zu verschwenden.
Ein Sprint stellt eine zeitlich begrenzte Gelegenheit dar, einen bestimmten Teil des komplexen Problems der Produktentwicklung zu untersuchen und eine Lösung zu erarbeiten. Die vier weiteren Scrum Events fördern die Überprüfung und Anpassung spezifischer Aspekte dieser Arbeit.
Ausblick: Im nächsten Teil sehen wir und das Sprint Planning näher an.
Wenn du Fragen hast, schreibe sie gerne in die Kommentare hier im Blog oder auf unserem Colenet-Linkedin-Account.
Hier findest du alle Teile der Reihe “Scrum im Selbststudium”:
Teil 1: Agile Projekte sind erfolgreicher
Teil 2: Scrum in 11 Schritten im Schnelldurchlauf erklärt
Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt
Teil 5: Die Grundlage eines funktionierenden empirischen Prozesses ist Vertrauen
Teil 6: Die Scrum Artefakte stellen Transparenz her
Teil 7: Die mögliche Zukunft – Das Product-Backlog
Teil 8: Die Gegenwart – Das Sprint Backlog
Teil 9: Die Vergangenheit – Das Produkt-Inkrement
Teil 10: Scrum Events erlauben, die Artefakte zu überprüfen und anzupassen
Teil 11: Sprint – Erstellung eines Inkrements
Teil 12: Sprint Planning – Planung der Arbeit des Sprints
Teil 14: Sprint Review – Überprüfung der Sprint-Ergebnisse und weitere Planung
Teil 15: Sprint Retrospektive – Aus dem vergangenen Sprint lernen und Verbesserungen planen
Teil 16: Das Scrum-Team und seine Verantwortung
Teil 17: Der Product Owner maximiert den Wert des Produkts
Teil 18: Die Entwickler schaffen jeden Sprint ein nutzbares Inkrement
Teil 19: Der Scrum Master verantwortet die Effektivität des Scrum-Teams