Backlog — ist eine geordnete Liste aller Aufgaben, Anforderungen und Verbesserungen, die in einem Projekt umgesetzt werden müssen. Es ist ein zentrales Artefakt agiler Methodiken: In Scrum wird das Backlog vom Product Owner verwaltet, in Kanban — vom gesamten Team. Laut Scrum Guide, 2020 ist das Backlog niemals abgeschlossen: Es entwickelt sich ständig zusammen mit dem Produkt und den Marktanforderungen weiter.
Wichtige Erkenntnisse
Backlog — ist eine einzige Quelle für Anforderungen aller Änderungen am Produkt. Der Product Owner ist für dessen Inhalt, Verfügbarkeit und Transparenz verantwortlich: Jedes Teammitglied muss verstehen, welche Aufgaben im Backlog sind und in welcher Reihenfolge sie umgesetzt werden.
Product Backlog enthält alle Projektaufgaben für die Zukunft — von Funktionen für das nächste Quartal bis zu Ideen fürs Jahr. Sprint Backlog ist eine Teilmenge von Aufgaben aus dem Product Backlog, die das Team in den aktuellen Sprint nimmt. Das Sprint Backlog wird während des Sprints eingefroren, während sich das Product Backlog ständig ändert.
In Scrum ist das Backlog streng strukturiert: Es gibt ein Product Backlog und ein Sprint Backlog, Aufgaben werden in Story Points geschätzt, Sprints haben eine feste Länge. In Kanban ist das Backlog flexibler: Aufgaben werden gezogen, sobald Entwickler verfügbar sind, Prioritäten können täglich wechseln, und WIP-Limits (Work in Progress) regulieren den Aufgabenfluss.
Ein qualitativ hochwertiges Backlog enthält verschiedene Arten von Aufgaben, nicht nur neue Funktionen. Ein ausgewogenes Backlog berücksichtigt alle Aspekte der Produktentwicklung.
| Elementtyp | Beschreibung | Beispiel |
|---|---|---|
| User Story | Neue Funktionalität aus Benutzersicht | „Als Benutzer möchte ich mein Passwort zurücksetzen“ |
| Bug | Fehler in bestehender Funktionalität | „Registrierungsbutton funktioniert nicht unter iOS 16“ |
| Tech Debt | Verbesserung der Codebasis ohne sichtbare Benutzerauswirkung | „Abhängigkeiten auf neueste Versionen aktualisieren“ |
| Spike / Research | Recherche oder Prototyp zur Risikominimierung | „Migration zu Jetpack Compose prüfen“ |
| Improvement | Verbesserung von Prozessen oder Infrastruktur | „CI/CD für automatisierte Builds einrichten“ |
Der Hauptbaustein des Backlogs ist die User Story (Benutzergeschichte). Eine qualitativ hochwertige User Story beschreibt, welchen Mehrwert der Benutzer erhält, nicht welche technischen Schritte durchgeführt werden müssen. INVEST-Format: Independent, Negotiable, Valuable, Estimable, Small, Testable. Eine Geschichte sollte in einen Sprint passen, andernfalls muss sie zerlegt werden.
Abnahmekriterien legen fest, wann eine Aufgabe als erledigt gilt. Sie werden im Given-When-Then-Format oder als einfache Liste von Bedingungen geschrieben. Beispiel: „Der Benutzer kann sein Passwort per E-Mail zurücksetzen, die E-Mail kommt innerhalb von 30 Sekunden an, der Link ist 24 Stunden gültig.“ Klare Abnahmekriterien vermeiden Diskussionen in der Demo-Phase.
Priorisierung ist der wichtigste und komplexeste Prozess der Backlog-Verwaltung. Der Product Owner muss Geschäftswert, Aufwand, Risiken und Abhängigkeiten zwischen Aufgaben berücksichtigen.
MoSCoW ist eine klassische Priorisierungsmethode. Must have — die Aufgabe ist kritisch fürs Produkt. Should have — eine wichtige Aufgabe, die verschoben werden kann. Could have — eine Verbesserung, die wünschenswert wäre. Won’t have — Aufgaben, die in die Zukunft verschoben werden. Verteilung: 60% Must, 20% Should, 20% Could. Die Methode hilft, sich auf kritische Funktionen zu konzentrieren.
Die Value-vs-Effort-Matrix teilt Aufgaben in vier Quadranten: Quick Wins (hoher Wert, geringer Aufwand) — zuerst erledigen, Big Bets (hoher Wert, hoher Aufwand) — vorausplanen, Fill-ins (niedriger Wert, geringer Aufwand) — zwischendurch erledigen, und Avoid (niedriger Wert, hoher Aufwand) — nicht machen. Dieser Ansatz maximiert den Wert bei begrenzten Ressourcen.
WSJF ist eine Priorisierungsmethode aus SAFe, basierend auf der Formel: Wert / Aufgabengröße. Je höher das Verhältnis von Wert zu Größe, desto höher die Priorität. WSJF berücksichtigt Geschäftswert, zeitliche Kritikalität und Risiken. Die Methode eignet sich für reife Produktteams mit einem großen Backlog-Volumen.
Effektives Backlog-Management erfordert regelmäßige Aktivitäten, die richtigen Tools und Disziplin des gesamten Teams.
Refinement ist ein regelmäßiges Meeting (normalerweise einmal pro Woche), bei dem das Team Backlog-Elemente klärt, schätzt und neu priorisiert. Der Scrum Guide empfiehlt, nicht mehr als 10% der Teamzeit fürs Refinement aufzuwenden. Ergebnis: Die oberen 20-30% des Backlogs sind bereit fürs Sprint-Planning — mit Schätzungen, Abnahmekriterien und Freigabe.
Die beliebtesten Tools fürs Backlog-Management: Jira (Branchenstandard mit flexibler Workflow-Konfiguration), Linear (schneller und moderner Tracker), Trello (für kleine Teams und Kanban), Notion (flexibler Arbeitsbereich mit Datenbanken) und YouTrack. Die Tool-Wahl hängt von Teamgröße, Methodik und Budget ab.
Selbst erfahrene Product Owners machen Fehler bei der Backlog-Verwaltung, die die Effektivität des Teams und die Produktqualität beeinträchtigen.
Der häufigste Fehler ist, alle Ideen ohne Filterung oder Priorisierung ins Backlog zu werfen. Das Backlog wächst auf Hunderte von Aufgaben an, sodass eine Navigation unmöglich wird. Lösung: Backlog regelmäßig bereinigen — veraltete Aufgaben entfernen, ähnliche zusammenführen, nicht dringende verschieben. Ein gesundes Backlog enthält 50-100 Einträge, nicht Tausende.
Wenn das Backlog nur aus User Stories besteht, wachsen technische Schulden und Infrastrukturverbesserungen werden aufgeschoben. Früher oder später stößt das Team aufgrund veralteter Abhängigkeiten, fehlender Tests oder Architekturprobleme an eine Leistungsgrenze. Regel: 20% der Aufgaben in einem Sprint sollten technisch sein — Refactoring, Tests, Updates.
Aufgaben 3-6 Monate im Voraus zu detaillieren ist Zeitverschwendung. Anforderungen ändern sich, der Markt entwickelt sich weiter, und detaillierte Aufgaben müssen umgeschrieben werden. Detaillieren Sie nur Aufgaben, die in die nächsten 1-2 Sprints gehen. Für weiter entfernte Aufgaben reichen Titel und Kurzbeschreibung.
Kleine Bugs landen nicht im Backlog, weil „keine Zeit” oder „wir reparieren es später.” Mit der Zeit sammeln sich Bugs an, die Qualität sinkt und das Produkt verliert das Vertrauen der Nutzer. Regel: Jeder Bug wird im Backlog erfasst, selbst bei niedriger Priorität. Wenn sich Bugs angehäuft haben — einen Sprint zu deren Behebung einplanen.
Häufig gestellte Fragen
Product Backlog ist die vollständige Liste aller Projektaufgaben für die langfristige Perspektive, verwaltet vom Product Owner. Sprint Backlog ist eine Teilmenge von Aufgaben aus dem Product Backlog, die das Team in den aktuellen Sprint nimmt. Das Sprint Backlog wird während des Sprints eingefroren, während sich das Product Backlog ständig ändert.
Fürs Backlog ist der Product Owner verantwortlich. Er legt Prioritäten fest, formuliert Aufgaben und entscheidet, wann Elemente sprintbereit sind. Entwickler können Änderungen vorschlagen, technische Aufgaben hinzufügen und die Komplexität schätzen, aber die endgültige Entscheidung über Prioritäten bleibt beim Product Owner.
Grooming wird einmal pro Woche oder mindestens einmal pro Sprint empfohlen. Der Scrum Guide empfiehlt, nicht mehr als 10% der Entwicklerzeit fürs Refinement aufzuwenden. Bei einem zweiwöchigen Sprint sind das etwa 1-2 Stunden pro Woche. Regelmäßiges Grooming verhindert die Ansammlung von „Müll“ im Backlog.
Ein gesundes Product Backlog enthält 50-100 Einträge. Weniger bedeutet, dass das Team nicht in die Zukunft denkt; mehr bedeutet, dass das Backlog zur Mülldeponie wird. Wichtig ist nicht die Anzahl der Einträge, sondern deren Qualität: Die oberen 20-30% sollten sprintbereit sein, der Rest in unterschiedlichem Detaillierungsgrad.
Das Product Backlog kann jederzeit geändert werden — das ist sein normaler Zustand. Das Sprint Backlog wird jedoch während des Sprints eingefroren, damit sich das Team auf das Ziel konzentrieren kann. Die einzige Ausnahme: Wenn der Product Owner eine Aufgabe aus dem Sprint entfernt, weil sie nicht mehr relevant ist.
Zusammenfassung
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch