Sprint Backlog in Scrum: Vollständiger Leitfaden mit Beispielen (2025)

Das Sprint Backlog besteht aus dem Sprint-Ziel (warum), der Menge der für den Sprint ausgewählten Product Backlog Elemente (was), sowie einem umsetzbaren Plan für die Lieferung des Inkrements (wie). Es ist ein hochsichtbares, Echtzeit-Bild der Arbeit, die die Entwickler während des Sprints zu erledigen planen, und es gehört ausschließlich ihnen.

Wichtige Unterscheidung: Während der Product Owner das Product Backlog und seine Ordnung besitzt, besitzen die Entwickler das Sprint Backlog. Sie entscheiden, welche Product Backlog Elemente ausgewählt werden und wie sie geliefert werden. Diese Eigentümerschaft befähigt Entwickler, ihre Arbeit selbst zu verwalten und schafft Verantwortlichkeit für Sprint-Commitments.

Kritische Erkenntnis: Das Sprint Backlog ist ein lebendes Artefakt, das sich während des gesamten Sprints entwickelt, während das Team mehr lernt. Es muss mindestens einmal täglich während des Daily Scrum aktualisiert werden, um aktuelle Pläne, aufkommende Aufgaben und Fortschritt zum Sprint-Ziel widerzuspiegeln. Das Sprint-Ziel selbst bleibt jedoch fest - es ändert sich nicht während des Sprints.

Schnelle Antwort: Sprint Backlog auf einen Blick

Aspekt	Details
Definition	Sprint-Ziel + ausgewählte Product Backlog Elemente + Lieferplan
Drei Komponenten	Warum (Sprint-Ziel) + Was (PBIs) + Wie (Aktionsplan)
Eigentümerschaft	Entwickler (erstellt während Sprint Planning, verwaltet während des gesamten Sprints)
Commitment	Sprint-Ziel (das einzelne Ziel für den Sprint)
Aktualisierungen	Mindestens einmal täglich; kontinuierlich verfeinert, wenn das Team mehr lernt
Sichtbarkeit	Hochsichtbar für das gesamte Scrum Team für Transparenz
Flexibilität	Spezifische Arbeit kann sich ändern; Sprint-Ziel bleibt fest
Erstellt während	Sprint Planning Event

In diesem umfassenden Leitfaden werden wir erkunden, wie man das Sprint Backlog erstellt, verwaltet und optimiert, um erfolgreiche Sprint-Ergebnisse zu erzielen.

Was ist das Sprint Backlog?

Laut dem Scrum Guide ist das Sprint Backlog eines der drei Kern-Scrum Artefakte (neben Product Backlog und Inkrement). Es dient als taktischer Plan der Entwickler zur Erreichung des Sprint-Ziels während des aktuellen Sprints.

Stellen Sie sich das Sprint Backlog als den commitment-getriebenen Arbeitsplan des Teams für den Sprint vor. Während das Product Backlog beantwortet "Was könnten wir für das Produkt bauen?", beantwortet das Sprint Backlog "Was werden wir in diesem Sprint bauen, und wie?"

Die drei Komponenten erklärt

1. Sprint-Ziel (Das "Warum") Das Sprint-Ziel ist ein einzelnes, kohärentes Ziel, das Zweck und Richtung für den Sprint bietet. Es schafft Fokus und fördert Zusammenarbeit statt isolierter Arbeit. Beispiel: "Benutzern ermöglichen, Produkte nach Kategorie zu suchen und zu filtern"

2. Ausgewählte Product Backlog Elemente (Das "Was") Dies sind die spezifischen PBIs, von denen die Entwickler vorhersagen, dass sie sie während des Sprints zur Erreichung des Sprint-Ziels abschließen können. Sie werden während Sprint Planning basierend auf Priorität und Teamkapazität ausgewählt. Beispiel: "User Story: Als Käufer möchte ich Produkte nach Stichwort suchen" + "User Story: Als Käufer möchte ich Suchergebnisse nach Kategorie filtern"

3. Umsetzbarer Plan (Das "Wie") Dies ist die detaillierte Aufschlüsselung von Aufgaben, Aktivitäten und technischer Arbeit, die benötigt wird, um jedes PBI abzuschließen und ein funktionierendes Inkrement zu liefern. Der Plan entsteht während des gesamten Sprints, wenn das Team mehr lernt. Beispielaufgaben: "Such-API entwerfen", "Stichwort-Suchalgorithmus implementieren", "Kategoriefilter UI-Komponente erstellen", "Integrationstests schreiben"

Zweck des Sprint Backlogs

Das Sprint Backlog dient als Plan des Scrum Teams für einen bestimmten Sprint und bietet mehrere wichtige Vorteile:

1. Fokus: Das Sprint Backlog hilft dem Entwicklungsteam, sich auf die Arbeitselemente zu konzentrieren, zu deren Fertigstellung sie sich während des Sprints verpflichtet haben.

2. Transparenz: Das Sprint Backlog bietet einen transparenten Überblick über die für den aktuellen Sprint geplante Arbeit und ermöglicht es dem Scrum Team und den Stakeholdern, den Fortschritt zu überwachen und die Verpflichtungen des Teams zu verstehen.

3. Anpassungsfähigkeit: Das Sprint Backlog ist ein dynamisches Artefakt, das vom Entwicklungsteam während des gesamten Sprints aktualisiert werden kann, um neue Erkenntnisse, aufkommende Anforderungen oder Änderungen der Priorität widerzuspiegeln.

4. Verantwortlichkeit: Das Sprint Backlog macht das Entwicklungsteam für die Lieferung der Arbeitselemente verantwortlich, zu deren Fertigstellung sie sich während des Sprints verpflichtet haben.

Struktur des Sprint Backlogs

Das Sprint Backlog hat drei miteinander verbundene Elemente, die zusammenarbeiten, um die Sprint-Ausführung zu leiten:

Element	Beschreibung	Beispiel
Sprint-Ziel	Einzelnes kohärentes Ziel für den Sprint	"Grundlegende E-Commerce-Checkout-Funktionalität ermöglichen"
Ausgewählte PBIs	Product Backlog Elemente, die zur Erreichung des Sprint-Ziels ausgewählt wurden	3-8 User Stories oder Features (variiert je nach Team)
Umsetzbarer Plan	Aufgaben, Aktivitäten und technische Arbeit zur Lieferung der PBIs	20-40 Aufgaben, die aus den PBIs abgeleitet wurden

Sprint-Ziel - Das Commitment

Das Sprint-Ziel ist das Commitment, das mit dem Sprint Backlog Artefakt verbunden ist. Es erfüllt mehrere kritische Funktionen:

Bietet Zweck: Gibt dem Sprint Bedeutung jenseits des bloßen Erledigens von Aufgaben. Teams verstehen warum sie die Arbeit machen.

Ermöglicht Flexibilität: Während das Ziel fest ist, kann die spezifische Arbeit angepasst werden. Wenn das Team einen besseren Weg zum Ziel entdeckt, kann es den Umfang mit dem Product Owner neu verhandeln.

Fördert Zusammenarbeit: Schafft ein vereinendes Ziel, das Teamarbeit fördert. Statt dass Einzelpersonen an separaten Stories arbeiten, arbeitet das Team auf ein gemeinsames Ergebnis hin.

Leitet Abwägungen: Wenn Konflikte auftreten (z.B. Zeitbeschränkungen), hilft das Sprint-Ziel Teams zu entscheiden, was wesentlich ist vs. was aufgeschoben werden kann.

Beispiele für Sprint-Ziele:

• ✅ Gut: "Benutzern ermöglichen, ihre Profile zu erstellen und zu verwalten"
• ✅ Gut: "Zahlungsabwicklung mit Kreditkartenunterstützung implementieren"
• ✅ Gut: "Seitenladezeit auf unter 2 Sekunden reduzieren"
• ❌ Schlecht: "5 User Stories abschließen" (kein kohärentes Ziel)
• ❌ Schlecht: "Am Backlog arbeiten" (zu vage)

Ausgewählte Product Backlog Elemente

Dies sind die PBIs, von denen die Entwickler vorhersagen, dass sie sie während des Sprints abschließen können. Hauptmerkmale:

• Vorhergesagt, nicht zugesagt: Das Team macht seine beste Vorhersage basierend auf historischer Velocity und Sprint-Kapazität
• Auf Sprint-Ziel ausgerichtet: Alle ausgewählten Elemente sollten zur Erreichung des Sprint-Ziels beitragen
• Verfeinert und bereit: Elemente sollten gut verstanden, geschätzt und die "Definition of Ready" des Teams erfüllen, falls vorhanden
• Angemessen dimensioniert: Elemente sollten innerhalb des Sprints abschließbar sein (typischerweise 1-5 Tage Arbeit pro Element)

Typische Sprint Backlog Größe:

• 2-Wochen-Sprint: 5-10 PBIs (variiert stark je nach Teamgröße und Elementkomplexität)
• Teams streben typischerweise 20-40 Stunden vorhergesagter Arbeit pro Entwickler an

Umsetzbarer Lieferplan

Der Lieferplan unterteilt PBIs in konkrete, handhabbare Aufgaben. Dies umfasst:

Technische Aufgaben: "Datenbankmigration erstellen", "REST API Endpunkt implementieren", "Unit Tests schreiben"

Design-Aufgaben: "Wireframes erstellen", "UI-Komponenten designen", "Barrierefreiheitskonformität prüfen"

Test-Aufgaben: "Integrationstests schreiben", "Lasttests durchführen", "Regressionstests ausführen"

Dokumentationsaufgaben: "API-Dokumentation aktualisieren", "Benutzerhandbuch erstellen", "Release Notes aktualisieren"

Abhängigkeiten und Reihenfolge: Verstehen, welche Aufgaben abgeschlossen sein müssen, bevor andere beginnen können

Erstellung des Sprint Backlogs während Sprint Planning

Das Sprint Backlog wird während des Sprint Planning Events durch einen kollaborativen Prozess erstellt:

Schritt 1: Sprint-Ziel formulieren (Erste Hälfte des Sprint Planning)

• Product Owner schlägt Sprint-Ziel basierend auf Product Backlog Prioritäten vor
• Das gesamte Scrum Team arbeitet zusammen, um das Sprint-Ziel zu verfeinern und zu vereinbaren
• Sprint-Ziel sollte innerhalb der Sprint-Zeitbox erreichbar sein und mit dem Produktziel übereinstimmen

Schritt 2: Product Backlog Elemente auswählen (Erste Hälfte des Sprint Planning)

• Entwickler prüfen die am höchsten geordneten Product Backlog Elemente
• Team diskutiert, was abgeschlossen werden kann, um das Sprint-Ziel zu erreichen
• Entwickler sagen vorher, wie viele Elemente sie basierend auf Folgendem abschließen können:
  • Historische Velocity (frühere Sprint-Leistung)
  • Team-Kapazität (Verfügbarkeit, Abwesenheiten, andere Verpflichtungen)
  • Element-Komplexität und Abhängigkeiten
• Product Owner klärt Anforderungen und beantwortet Fragen

Schritt 3: Lieferplan erstellen (Zweite Hälfte des Sprint Planning)

• Entwickler unterteilen ausgewählte PBIs in Aufgaben
• Team identifiziert technische Ansätze, Abhängigkeiten und Risiken
• Plan ist detailliert genug, um Fortschritt während Daily Scrum zu verfolgen
• Initiale Aufgabenschätzungen helfen, Sprint-Vorhersage zu validieren

Beispiel Sprint Planning Ergebnis:

• Sprint-Ziel: "Benutzern ermöglichen, ihren Warenkorb zu verwalten"
• Ausgewählte PBIs:
  • User Story: Artikel zum Warenkorb hinzufügen
  • User Story: Artikel aus Warenkorb entfernen
  • User Story: Artikelmengen aktualisieren
  • Fehlerbehebung: Warenkorb-Gesamtberechnungsfehler
• Initiale Aufgaben: ~25 identifizierte Aufgaben über Design, Entwicklung, Tests

Verwaltung des Sprint Backlogs während des gesamten Sprints

Die Entwickler besitzen und aktualisieren kontinuierlich das Sprint Backlog während des gesamten Sprints:

Tägliche Aktualisierungen (Minimum)

• Sprint Backlog muss mindestens einmal täglich während Daily Scrum aktualisiert werden
• Entwickler inspizieren Fortschritt zum Sprint-Ziel
• Neu entdeckte Aufgaben hinzufügen, wenn das Team mehr lernt
• Abgeschlossene Aufgaben markieren und verbleibende Arbeitsschätzungen aktualisieren
• Hindernisse identifizieren und sichtbar machen, die den Fortschritt blockieren

Kontinuierliche Verfeinerung

• Aufgaben entstehen während des gesamten Sprints - nicht alles ist beim Sprint Planning bekannt
• Team zerlegt PBIs in feinere Aufgaben, während die Arbeit fortschreitet
• Technische Entdeckungen können neue Aufgaben oder Ansätze erfordern
• Definition of Done Einhaltung zeigt oft zusätzliche Arbeit auf

Umfangsverhandlung bei Bedarf

• Wenn Sprint-Ziel erreichbar bleibt, aber Umfang angepasst werden muss, verhandeln Entwickler mit Product Owner
• Können PBIs durch gegenseitige Vereinbarung entfernen oder hinzufügen, solange Sprint-Ziel nicht gefährdet wird
• Product Owner kann Sprint abbrechen, wenn Sprint-Ziel obsolet wird

Hauptverantwortlichkeiten:

1. Neue Aufgaben hinzufügen: Wenn Entwickler mehr lernen, fügen sie Aufgaben zum Sprint Backlog hinzu
2. Fortschritt aktualisieren: Aufgaben als in Bearbeitung oder erledigt markieren, Zeitschätzungen aktualisieren
3. Sichtbarkeit aufrechterhalten: Sicherstellen, dass Sprint Backlog für alle zugänglich und transparent ist
4. Plan anpassen: Ansatz basierend auf Hindernissen, Entdeckungen oder neuen Informationen anpassen

Sprint Backlog vs Product Backlog: Hauptunterschiede

Aspekt	Product Backlog	Sprint Backlog
Eigentümerschaft	Product Owner	Entwickler
Umfang	Gesamtes Produkt (alle zukünftige Arbeit)	Nur aktueller Sprint
Zeithorizont	Produktlebensdauer (Monate/Jahre)	Ein Sprint (1-4 Wochen)
Commitment	Produktziel (langfristig)	Sprint-Ziel (kurzfristig)
Ordnung	Nach Wert, Risiko, Abhängigkeiten geordnet	Nach Lieferplan sequenziert
Änderungen	Kann jederzeit geändert werden	Änderungen mit Sprint-Ziel-Einschränkungen
Granularität	Variiert (detailliert oben, vage unten)	Detailliert genug für Daily Scrum
Inhalt	Features, Erweiterungen, Bugs, technische Arbeit	Ausgewählte PBIs + Aufgaben + Sprint-Ziel

Beziehung: Das Product Backlog speist das Sprint Backlog. Während Sprint Planning zieht das Team Elemente von der Spitze des Product Backlogs ins Sprint Backlog.

Häufige Fehler beim Sprint Backlog

Fehler #1: Product Owner kontrolliert Sprint Backlog

Problem: Product Owner diktiert, an welchen Aufgaben Entwickler arbeiten, oder fügt/entfernt Elemente aus dem Sprint Backlog ohne Entwickler-Zustimmung.

Warum es problematisch ist: Verletzt Scrums Selbstverwaltungsprinzip. Entwickler können nicht für Commitments verantwortlich gemacht werden, die sie nicht gemacht haben.

Lösung:

• Product Owner besitzt Ordnung des Product Backlogs
• Entwickler besitzen Sprint Backlog und entscheiden, welche Arbeit sie vorhersagen
• Änderungen am Sprint Backlog während des Sprints erfordern gegenseitige Vereinbarung

Fehler #2: Kein Sprint-Ziel oder schwaches Sprint-Ziel

Problem: Team überspringt Sprint-Ziel oder erstellt vage Ziele wie "8 Story Points abschließen" oder "An Backlog-Elementen arbeiten".

Warum es problematisch ist: Ohne kohärentes Ziel arbeitet das Team in Silos. Keine Flexibilität, Umfang anzupassen, wenn Herausforderungen auftreten.

Lösung:

• Bedeutungsvolles Sprint-Ziel formulieren, das Wert oder Ergebnis beschreibt
• Sicherstellen, dass alle ausgewählten PBIs zum Sprint-Ziel beitragen
• Sprint-Ziel verwenden, um Abwägungen während des Sprints zu leiten

Fehler #3: Sprint Backlog nicht täglich aktualisieren

Problem: Sprint Backlog beim Sprint Planning erstellt, aber nie aktualisiert, oder nur einmal pro Woche aktualisiert.

Warum es problematisch ist: Verfehlt den Transparenzzweck. Team und Stakeholder können echten Fortschritt nicht inspizieren oder sich an Änderungen anpassen.

Lösung:

• Sprint Backlog mindestens während Daily Scrum aktualisieren
• Neue Aufgaben hinzufügen, sobald sie entdeckt werden
• Burndown/Burnup-Charts aktuell halten
• Sprint Backlog für alle sichtbar machen

Fehler #4: Sprint Backlog als festen Vertrag behandeln

Problem: Team weigert sich, Sprint Backlog anzupassen, selbst wenn Sprint-Ziel gefährdet ist oder neue Informationen auftauchen.

Warum es problematisch ist: Scrum ist empirisch - Teams sollten sich basierend auf Lernen anpassen. Starres Festhalten am ursprünglichen Plan ignoriert die Realität.

Lösung:

• Sprint-Ziel ist fest; spezifische Arbeitselemente können sich ändern
• Aufgaben hinzufügen oder entfernen, wenn das Team mehr lernt
• Umfangsänderungen mit Product Owner verhandeln, wenn nötig
• Auf Erreichung des Sprint-Ziels fokussieren, nicht auf Abschluss jeder Aufgabe

Fehler #5: Sprint überverpflichten

Problem: Team wählt mehr PBIs aus, als sie realistisch abschließen können, in der Hoffnung, die Leistung zu "steigern".

Warum es problematisch ist: Führt zu unvollständiger Arbeit, hastiger Qualität und Team-Burnout. Untergräbt Vertrauen bei Stakeholdern.

Lösung:

• Vorhersage auf historischer Velocity basieren, nicht auf Wunschdenken
• Team-Kapazität berücksichtigen (Meetings, Abwesenheiten, Support-Arbeit)
• Besser unter-verpflichten und möglicherweise mehr Arbeit ziehen als über-verpflichten und scheitern

Fehler #6: Zu viel oder zu wenig Detail in Aufgaben

Problem: Aufgaben sind entweder zu granular ("Zeile 47 des Codes schreiben") oder zu grob ("Feature implementieren").

Warum es problematisch ist: Zu detailliert erzeugt administrativen Aufwand; zu grob verhindert effektive Daily Scrum Inspektion.

Lösung:

• Aufgaben anstreben, die 2-8 Stunden zur Fertigstellung benötigen
• Aufgaben sollten klein genug sein, um täglichen Fortschritt zu verfolgen
• Groß genug, um Mikromanagement zu vermeiden
• "Wenn Sie es nicht an einem Tag beenden können, unterteilen Sie es weiter"

Best Practices für Sprint Backlog Management

1. Sprint Backlog visualisieren

Physische Boards oder digitale Tools nutzen, um Sprint Backlog sichtbar zu machen:

• Kanban-Board: Zu erledigen → In Bearbeitung → Erledigt
• Aufgaben-Board: Aufgaben nach PBI gruppieren
• Burndown-Chart: Verbleibende Arbeit über Sprint verfolgen
• Burnup-Chart: Abgeschlossene Arbeit zum Sprint-Ziel verfolgen

2. Nachhaltiges Tempo aufrechterhalten

• Nicht für 100% Kapazität planen - Meetings, E-Mails, Unterbrechungen berücksichtigen
• Typische Planung: 5-6 produktive Stunden pro Entwickler pro Tag
• Puffer für unerwartete Arbeit und Hindernisse lassen
• Team-Energie und Moral überwachen

3. Auf Sprint-Ziel-Arbeit schwärmen

• Zusammenarbeit über individuellen Aufgabenabschluss fördern
• "Wie können wir das Sprint-Ziel erreichen?" vs. "Wie kann ich meine Aufgaben beenden?"
• Pair Programming und Mob Programming für komplexe Arbeit
• Teammitgliedern helfen, bevor neue Arbeit begonnen wird

4. Sprint-Ziel sichtbar halten

• Sprint-Ziel prominent auf Team-Board anzeigen
• Sprint-Ziel während Daily Scrum referenzieren
• Sprint-Ziel zur Priorisierung nutzen, wenn mehrere Aufgaben bereit sind
• Fragen "Trägt diese Arbeit zum Sprint-Ziel bei?"

5. Tests während des gesamten Sprints integrieren

• Tests nicht für Ende des Sprints aufsparen
• Test-Aufgaben in Lieferplan einbeziehen
• Jedes PBI testen, sobald Entwicklung abgeschlossen ist
• Nichts ist "erledigt", bis es die Definition of Done erfüllt

6. Fortschritt mit Metriken verfolgen

• Burndown-Chart: Zeigt verbleibende Arbeit über Zeit
• Burnup-Chart: Zeigt angesammelte abgeschlossene Arbeit
• Aufgabenabschluss: Anzahl erledigter vs. verbleibender Aufgaben
• Sprint-Ziel-Vertrauen: Tägliche Team-Einschätzung der Sprint-Ziel-Erreichbarkeit

7. Basierend auf Hindernissen anpassen

• Hindernisse während Daily Scrum sichtbar machen
• Sprint Backlog aktualisieren, um Auswirkungen von Blockern widerzuspiegeln
• Scrum Master arbeitet daran, Hindernisse zu beseitigen
• Wenn Sprint-Ziel unerreichbar wird, mit Product Owner diskutieren

Fazit

Das Sprint Backlog ist ein kritisches Scrum Artefakt, das strategische Product Backlog Elemente in taktische Sprint-Ausführungspläne transformiert. Durch die Kombination des Sprint-Ziels (warum), ausgewählter Product Backlog Elemente (was) und umsetzbarem Lieferplan (wie) bietet das Sprint Backlog Fokus, Transparenz und Anpassungsfähigkeit für Scrum Teams.

Wichtigste Erkenntnisse:

1. Drei Komponenten: Sprint-Ziel + ausgewählte PBIs + Lieferplan arbeiten zusammen
2. Entwickler-Eigentümerschaft: Nur Entwickler kontrollieren Sprint Backlog Inhalt und Aktualisierungen
3. Sprint-Ziel ist Commitment: Festes Ziel bietet Fokus und ermöglicht Flexibilität
4. Tägliche Aktualisierungen erforderlich: Mindestens einmal täglich, kontinuierlich wenn Team lernt
5. Emergent und anpassungsfähig: Plan entwickelt sich während des gesamten Sprints basierend auf neuen Informationen
6. Sichtbar für alle: Transparenz ermöglicht Inspektion und unterstützt Zusammenarbeit

Effektives Sprint Backlog Management befähigt Teams, wertvolle Inkremente vorhersagbar zu liefern und sich gleichzeitig an wechselnde Umstände und neue Entdeckungen anzupassen.

Häufig gestellte Fragen (FAQs)