Sprint-Backlog im Scrum: Was bedeutet das?

Das Sprint-Backlog ist eine Reihe von Produkt-Backlog-Einträgen, die für das aktuelleSprint, zusammen mit einem Plan zur Lieferung eines Produkt-Updates, um dasSprint-Ziel. Das Sprint-Backlog definiert, welche Funktionen das Entwicklungsteam im nächsten Inkrement einschließen möchte und welche Arbeit erforderlich ist, um sie zu liefern.

Scrum-Sprint-Backlog

Das Sprint-Backlog definiert die Arbeit, die das Entwicklungsteam erledigen muss, um Produkt-Backlog-Einträge in ein „fertiges“ Update zu verwandeln. Es klärt die für das Entwicklungsteam erforderliche Arbeit, um das Sprint-Ziel zu erreichen.

Sprint-Backlog

Das Sprint-Backlog ist ein ausreichend detaillierter Plan, der während desDaily Scrumverfolgt werden kann. Das Entwicklungsteam verfeinert das Sprint-Backlog kontinuierlich während des Sprints, und es entwickelt sich allmählich weiter – beispielsweise, wenn das Team nach Plan arbeitet und tiefere Einsichten in die für die Erreichung des Sprint-Ziels erforderliche Arbeit gewinnt.

Wenn neue Arbeit entsteht, muss das Entwicklungsteam sie dem Sprint-Backlog hinzufügen. Wenn Aufgaben fortschreiten oder abgeschlossen sind, muss die geschätzte verbleibende Arbeitszeit für jede Aufgabe aktualisiert werden. Wenn ein Teil des Plans an Entwicklungsnutzen verliert, kann er entfernt werden. Nur das Entwicklungsteam darf das Sprint-Backlog während des Sprints verändern. Das Sprint-Backlog ist hochsichtbar und spiegelt in Echtzeit den Plan der Mannschaft für die während des aktuellen Sprints abgeschlossene Arbeit wider – es gehört ausschließlich dem Entwicklungsteam.

Da Produkt-Backlog-Einträge innerhalb eines Sprint-Zyklus festgelegt sind, können die folgenden Gründe zu Änderungen im Sprint-Backlog führen:

• Mit der Zeit kann das Entwicklungsteam ein besseres Verständnis der Anforderungen gewinnen und die Notwendigkeit erkennen, neue Aufgaben zum Sprint-Backlog hinzuzufügen.
• Defekte werden als neue Aufgaben hinzugefügt – dies sind unvollständige Einträge aus früheren Sprints.

DerProduct Ownerkann mit demScrum-Teamzusammenarbeiten, um dem Team zu helfen, das Sprint-Ziel besser zu verstehen. DerScrum Masterund das Team können geringfügige Anpassungen in Betracht ziehen, die den Sprint-Verlauf nicht beeinflussen, aber dem Kunden einen größeren geschäftlichen Nutzen bringen könnten.

Überwachung des Sprint-Fortschritts

Zu jedem Zeitpunkt während des Sprints kann die Gesamtmenge der verbleibenden Arbeit im Sprint-Backlog berechnet werden. Das Entwicklungsteam verfolgt die verbleibende Arbeit mindestens während des Daily Scrum und prognostiziert die Wahrscheinlichkeit, das Sprint-Ziel zu erreichen. Durch die Verfolgung weiterer Arbeiten während des Sprints kann das Team seinen Fortschritt effektiv managen.

Scrumberücksichtigt die dafür aufgewendete Zeit nicht. Wir kümmern uns nur um die verbleibende Arbeit und die Zeitvariable.

Verwendung von Burndown-Diagrammen zur Nachverfolgung

Sprint-Burndown-Diagrammezeigen die kumulierte verbleibende Arbeit während des Sprints und spiegeln die Tendenz der Arbeitsabwicklung wider. Die Y-Achse stellt die verbleibende Arbeit dar, und die X-Achse die Arbeitstage des Sprints.

Verbrauchsdiagramm

Zu Beginn des Sprints identifiziert das Scrum-Team die detaillierten Aufgaben, die abgeschlossen werden müssen, und schätzt diese ein. Alle Aufgaben, die abgeschlossen werden müssen, aber noch nicht abgeschlossen sind, gelten als kumulative Arbeit. Das Team aktualisiert die kumulative Arbeit täglich basierend auf dem Fortschritt. Wenn die kumulative Arbeit am Ende des Sprints null erreicht, ist der Sprint erfolgreich abgeschlossen.

Release-Verbrauchsdiagramm

In einem Scrum-Projekt verfolgt das Team den Gesamtfortschritt der Freigabe, indem es das Release-Verbrauchsdiagramm am Ende jedes Sprints aktualisiert. Das Release-Verbrauchsdiagramm dokumentiert die Entwicklung der insgesamt geschätzten verbleibenden Arbeit im Sprint-Backlog über einen Zeitraum. Die X-Achse stellt den Sprint-Zyklus dar, und die Y-Achse stellt die verbleibende Arbeit dar, typischerweise gemessen in User Stories, idealen Personentagen oder Teamtagen.