In der agilen Softwareentwicklung ist das Backlog ein Ort, an dem Teams Produktideen und Aufgaben, an denen sie in Zukunft arbeiten könnten, speichern und priorisieren.
Selbst in agilen Kreisen bereitet der Begriff jedoch oftmals Probleme, da es zwei Arten von Backlogs gibt - das Product Backlog und das Sprint Backlog. Während die meisten Teams das Product Backlog gut verstehen, ist ihr Verständnis des Sprint Backlogs vielleicht etwas weniger klar.
Dieser Artikel erklärt, wie man in jedem Sprint ein effektives Sprint Backlog erstellt und pflegt:
- Was ist ein Sprint Backlog?
- Sprint Backlog vs. Product Backlog: Was ist der Unterschied?
- Wie man ein Sprint Backlog in der Sprintplanung erstellt
- Aktualisieren des Sprint Backlogs während des Sprints
Was ist ein Sprint Backlog?
Das Sprint Backlog ist eine Liste von Arbeiten, die ein agiles Team während eines Sprints abschliessen möchte. Sprint Backlogs werden in verschiedenen agilen Frameworks verwendet, darunter Scrum und abgeleitete Frameworks wie Scrumban, Scrum of Scrums und LeSS.
Der offizielle Scrum Guide unterteilt das Sprint Backlog in drei Komponenten:
- Das Sprint Goal, das das Ziel des Sprints angibt.
- Die für den Sprint ausgewählten Arbeitselemente - normalerweise in Form von User Stories -, die dazu beitragen, das Sprint Goal zu erreichen.
- Ein umsetzbarer Plan für die Bereitstellung der Arbeitselemente, die oft als kleinere Aufgaben aufgeführt werden, die zu den grösseren Aufgaben beitragen.
Viele Teams entscheiden sich dafür, auch Grössenschätzungen für jede Aufgabe hinzuzufügen - in Stunden oder Story Points - und verwenden Planning Poker, um zu bestimmen, wie viele Elemente in einen Sprint passen.
Ein grundlegender Ansatz zur Erstellung eines Sprint Backlogs ist die Verwendung einer Tabellenkalkulation. Die meisten Teams verwenden jedoch ein Sprint Board oder Task Board in einem Backlog-Tool wie Jira oder GitHub - mit Spalten, die anzeigen, ob etwas geplant, in Arbeit, festgefahren oder abgeschlossen ist.
Das Sprint Backlog schafft Klarheit und hilft dem Team zu wissen, worauf es sich in jedem Sprint konzentrieren soll. Da die Sprint Backlog-Elemente oft in einem digitalen Tool mit ihrem Status dokumentiert werden - zu tun, in Arbeit, erledigt -, können auch andere Stakeholder darauf verweisen, um sich in Echtzeit ein Bild davon zu machen, was das Team während seines Sprints zu erreichen plant und wie der aktuelle Stand seiner Arbeit ist.
Sprint Backlog vs. Product Backlog: Was ist der Unterschied?
Der Product Owner ist für die effektive Verwaltung des Product Backlogs verantwortlich. Dazu gehört die Pflege und Priorisierung des Product Backlogs, das die Product Backlog Items (PBIs) enthält - alle Ideen, an denen ein Team möglicherweise arbeiten könnte, um sein Produkt zu entwickeln.
Das Sprint Backlog gehört den Entwicklern und besteht aus Elementen, die sie aus dem Product Backlog ausgewählt haben, um während eines Sprints daran zu arbeiten.
Sie können sich das Product Backlog wie eine Landkarte vorstellen, mit vielen attraktiven Orten, die Sie besuchen könnten, aber nicht in einer Reise (Ihrem Sprint). Für jede Reise müssen Sie ein Ziel auswählen (Ihr Sprint Goal). Um dorthin zu gelangen, benötigen Sie eine Route (das Sprint Backlog) und eine Anleitung zum Abbiegen (die darin enthaltenen Work Items, aber auch die User Stories und Akzeptanzkriterien, aus denen Ihre Aufgaben bestehen).
Wie man ein Sprint Backlog in der Sprintplanung erstellt
Agile Teams erstellen in der Regel gemeinsam ein Sprint Backlog während ihrer Sprint Planning Meetings. Die Teammitglieder wählen Arbeitselemente aus dem Product Backlog aus und verschieben sie in das Sprint Backlog. Wenn Sie ein Kanban-Board verwenden, läuft dies auf das Verschieben von Elementen aus dem Backlog in die Todo-Spalte hinaus.
Bevor die Sprintplanung beginnt, stellt der Product Owner sicher, dass die relevanten Workitems im Product Backlog angemessen priorisiert und detailliert ist.
Ablauf der Sprint Planung
- Setzen Sie ein einheitliches Sprint-Ziel.
- Auswahl von Working Items, die zum Erreichen des Sprint Goals beitragen.
- Überprüfen des Sprint Backlogs, um sicherzustellen, dass der richtige Arbeitsumfang prognostiziert wurde.
Die Erstellung des Sprint Goals zusammen mit dem Product Owner und dem Scrum Master ist der erste Schritt in der Sprintplanung. Das Sprint Goal ist Ihr Nordstern, um zu entscheiden, welche Elemente vom Product Backlog in das Sprint Backlog verschoben werden sollen.
Obwohl der Scrum Guide in diesem Punkt etwas vage ist, wird allgemein davon ausgegangen, dass der Product Owner die Erstellung des Sprint Goals leitet, indem er ein Ziel in das Sprint Planning Meeting einbringt.
Dieses Ziel kann dann verfeinert, angepasst und finalisiert werden, wenn das gesamte Team den Plan diskutiert und Elemente für das Sprint Backlog auswählt.
Scrum-Trainer Simon Kneafsey veranschaulicht diesen Prozess auf Scrum.org anhand des Beispiels einer Bäckerei in Grossbritannien.
Das unmittelbare Produktziel des Product Owners ist es, "eine Website einzurichten, die den Verkauf an Kunden innerhalb Londons ermöglicht". Bei der Besprechung während der Sprintplanung ist sich das Team einig, dass es mehrere Sprints braucht, um dieses Produktziel zu erreichen, also setzen sie als Sprintziel für ihren ersten Sprint die Erstellung einer grundlegenden Website-Struktur.
Sobald Sie das Sprint Goal festgelegt haben, wählt das Team Elemente aus, die in das Sprint Backlog aufgenommen werden, um das Ziel zu erreichen. Im Beispiel der Bäckerei könnten dies drei mögliche Strukturen für die neue Website sein, die mit mehreren Kunden durch visuelle Mockups getestet werden.
Das Team listet dann die kritischsten kleineren Aufgaben im Zusammenhang mit diesen Punkten auf, um festzustellen, ob die Arbeit in einen Sprint passt.
Sie können sicherstellen, dass der Umfang des Backlogs angemessen ist, indem Sie agile Metriken wie Velocity, Cycle Time oder ein Burndown-Diagramm verwenden, um festzustellen, ob der Umfang der von Ihrem Team geplanten Arbeit im Vergleich zu Ihrer historischen Leistung realistisch ist.
📌 Hinweis: Vergessen Sie nicht, die Ergebnisse früherer Sprint-Retrospektiven bei Bedarf als Arbeitsaufgaben in den nächsten Sprint zu übernehmen. Diese Praxis stellt sicher, dass Sie Ihre Arbeitsprozesse kontinuierlich verbessern.
Aktualisieren des Sprint Backlogs während des Sprints
Die Entwickler können ihre Arbeitsplanung während des Sprints ändern, wenn dies dazu beiträgt, das Sprint Goal zu erreichen oder ausgewählte Arbeitselemente abzuschliessen. Es sollten jedoch keine Änderungen vorgenommen werden, die das Sprint Goal gefährden.
Da die Entwickler für das Erreichen des Sprint Goals verantwortlich sind, können die Product Owner - oder andere Stakeholder - keine Anpassungen vornehmen. Sie sollten lediglich die Prioritäten und ihre Vision beim nächsten Sprint Planning Meeting festlegen.
Die Entwickler sollten das Sprint Backlog im Laufe des Sprints aktualisieren, wenn sich ihr Verständnis von und ihr Fortschritt bei bestimmten Arbeitselementen weiterentwickelt. Diese Aktualisierungen finden während des Daily Scrum statt, dessen Zweck im offiziellen Scrum Guide wie folgt beschrieben wird: "den Fortschritt auf dem Weg zum Sprint Goal zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, indem die anstehende geplante Arbeit angepasst wird."
Übliche Aktualisierungen des Sprint Backlogs sind das Hinzufügen oder Entfernen von Aufgaben aus User Stories und das Aktualisieren des Fortschritts bei der Aufgabenerledigung. Wenn bestimmte Stories oder andere wesentliche Arbeitselemente unvorhergesehene Herausforderungen verursachen, können die Entwickler und der Product Owner zusammenarbeiten, um den Umfang anzupassen, solange dies nicht das Sprint Goal beeinträchtigt.
Starke Scrum-Praktiken fördern einen effektiven Sprint
Ihr Sprint Backlog ist ein wesentliches Scrum-Artefakt, das Sie in jedem Zyklus erstellen und aktualisieren werden. Es ist jedoch nur dann effektiv, wenn Sie seinen Zweck verstehen und andere Scrum-Praktiken befolgen - die Festlegung eines klaren Sprint-Ziels, die Verfeinerung des Product Backlogs und die Übertragung der Verantwortung für das Sprint Backlog an das Entwicklungsteam.
Ohne solche Prozesse wird Ihr Sprint Backlog irrelevant, da es zu einer gemeinsam genutzten Aufgabenliste wird, auf die jeder zu jeder Zeit Arbeit werfen kann.
