Häufige Ursachen für übervolle Backlogs – wie wir sie erkennen und was wir dagegen tun können
Im Jahr 2016 übernahm ich zum ersten Mal die Rolle des Product Owners. Das Team befand sich bereits im zweiten Sprint, und an meinem ersten Tag erhielt ich ein Product Backlog mit 142 Einträgen. Ich verbrachte zwei Wochen damit, die Einträge zu analysieren, sie zu beschreiben und gemeinsam mit dem Team den groben Aufwand abzuschätzen. Am letzten Tag des Sprints entschied ich mich, alle Einträge zu löschen.
Das Feedback der Stakeholder im Sprint Review zeigte mir deutlich, dass der Weg der Produktentwicklung nicht linear verläuft. Anders als in Projekten mit festen Plänen wissen wir in der Softwareentwicklung oft nicht genau, was als Nächstes kommt. Es gleicht eher einer Fahrt durch nebliges Gewässer, bei der wir erst nach und nach die Hindernisse erkennen.
Diese Unsicherheit ist ein natürlicher Bestandteil der Produktentwicklung, mit dem wir umgehen müssen.
Versucht dein Team, diese Ungewissheit mit einem detaillierten Backlog zu kompensieren?
Dann ist dieser Artikel für dich. Ich schildere dir vier Fehlvorstellungen, die über Product Backlogs kursieren. Auf alle vier bin ich während meiner Arbeit in Scrum-Teams verschiedener Unternehmen gestoßen.
Die Auswirkung dieser Fehlverwendung des Product Backlogs sah in allen Fällen gleich aus: Große und unübersichtliche Backlogs, die dem Team wertvolle Zeit kosteten.
Doch ist die Ursache erst einmal gefunden, gibt es Möglichkeiten, wie du die Situation für dein Team erheblich verbessern kannst. Lass uns loslegen:
1. Das Product Backlog ist keine Liste aller technischen Aufgaben
Das Scrum-Rahmenwerk beschreibt klar die Trennung von Product Backlog und Sprint Backlog:
- Das Product Backlog beschreibt das „Was“.
- Das Sprint Backlog beschreibt das „Wie“.
Diese klare Aufteilung unterstützt den Product Owner dabei, die Arbeit nach dem größten potenziellen Wert für das Produkt zu priorisieren. Gleichzeitig können die Developer ihre Aufgaben im Sprint nach technischen Kriterien sortieren und festlegen, wann und wer welche Aufgabe übernimmt. Werden technische Aufgaben jedoch ins Product Backlog aufgenommen, kann dies sowohl den Product Owner als auch die Developer in ihrer Arbeit einschränken. Zudem führt die Notwendigkeit mehrerer technischer Aufgaben zur Umsetzung einer neuen Funktion oft dazu, dass das Product Backlog unnötig anwächst und an Übersichtlichkeit verliert.
Lösung: Fasse die technischen Anforderungen in User Stories zusammen
Wenn das Product Backlog hauptsächlich aus technischen Aufgaben besteht, haben mir in der Vergangenheit folgende Fragen geholfen, das Backlog zu straffen:
- Wer profitiert von dieser Aufgabe?
- Was wird dieser Person dadurch ermöglicht?
Wenn beispielsweise eine technische Aufgabe „Abfrage der Nutzerdaten aus der Datenbank“ lautet, könnten die Antworten auf die Fragen, wer profitiert und was dadurch ermöglicht wird, sein: Ein Nutzer, der seine Profileinstellungen ändern möchte.
Diese Fragen helfen dabei, technische Aufgaben in potenzielle User Stories umzuwandeln. Eine mögliche User Story könnte lauten: „Als ‚häufiger Vertipper‘ möchte ich meinen Namen und meine Adresse in den Profileinstellungen korrigieren, damit die Bestellung an die richtige Adresse geliefert wird.“
Da für die Umsetzung dieser Story mehrere technische Aufgaben erforderlich sind, können diese Aufgaben zu einer Story zusammengefasst werden. Die Story wird dann zu einem Eintrag im Product Backlog, während die einzelnen technischen Aufgaben als Tasks im Sprint Backlog geführt werden.
Durch die Anwendung dieser Fragen kannst du die Liste technischer Aufgaben in ein klar strukturiertes Product Backlog umwandeln.
2. Das Product Backlog ist kein Werkzeug zur Team-Koordination
Wenn wir die Ungewissheit in der Produktentwicklung akzeptieren und verstehen, dass detaillierte Pläne diese Unsicherheit nicht beseitigen können, stellt sich die Frage, wie wir das Risiko dennoch minimieren können. Scrum bietet dafür zwei zentrale Werkzeuge:
- Sprints: Ein fester Zeitrahmen, der die Investitionen des Unternehmens in ein Projekt begrenzt. Mit Investitionen meine ich hier die Kosten, die durch die Arbeit der Teammitglieder für das Unternehmen entstehen.
- Scrum-Team: Ein interdisziplinäres Team, das alle notwendigen Fähigkeiten vereint, um innerhalb eines Sprints eine neue Produktversion zu entwickeln, die den Qualitätsanforderungen des Unternehmens entspricht.
Treten jedoch Abhängigkeiten zwischen mehreren Teams auf, wie etwa zwischen einem Design- und einem Entwicklungsteam, entstehen Risiken. Verzögert sich das Design, kann das Entwicklungsteam später beginnen, was das Risiko erhöht, dass die Arbeit nicht innerhalb eines Sprints abgeschlossen wird. Dadurch steigen die Kosten, weil ein zusätzlicher Sprint notwendig wird. Statt vier Wochen dauert es nun acht Wochen, bis die Kunden die neue Produktversion im Review beurteilen können.
Das Verwalten dieser Abhängigkeiten im Product Backlog, etwa durch das Erstellen von getrennten Design- und Entwicklungseinträgen, macht das Risiko lediglich sichtbar, löst es aber nicht. Um dieses Risiko vollständig zu eliminieren, sind interdisziplinäre Teams erforderlich, die alle benötigten Fähigkeiten vereinen und so Abhängigkeiten vermeiden.
Lösung: Erstelle eine Fähigkeitenmatrix
Um von getrennten Design- und Entwicklungsteams zu interdisziplinären Teams überzugehen, hat mir in der Vergangenheit die Erstellung einer Fähigkeitenmatrix geholfen. Diese Matrix zeigt auf, welche Kompetenzen im Team erforderlich sind, um einen Eintrag entsprechend der Definition of Done abzuschließen. Gleichzeitig macht sie transparent, welche Fähigkeiten dem Team noch fehlen.
So kann eine Fähigkeitenmatrix aussehen:
Erinnern wir uns daran: Das Product Backlog ist kein Koordinationswerkzeug. Interdisziplinäre Teams geben uns nun die Möglichkeit, das Product Backlog nach Wert zu ordnen und nicht nach der Bearbeitungsreihenfolge.
3. Das Product Backlog ist kein Releaseplan
Ein Releaseplan legt fest, welche Features bis zu welchem Zeitpunkt veröffentlicht werden sollen und welche Schritte dafür erforderlich sind. Oft ähnelt dieser Plan einer Checkliste mit wiederkehrenden Aufgaben, die bei jedem Release anfallen, wie:
- Vergabe einer Versionsnummer
- Erstellung der Release-Notes
- Erstellung von Nutzer-Dokumentationen
- Schulung von Support und Vertrieb
Im Scrum-Prozess sind Releases unabhängig von den Sprints. Die für ein Release notwendigen Aktivitäten werden in der Definition of Done berücksichtigt. Wenn ein Release jedoch mit vielen Aufgaben und erheblichem Aufwand verbunden ist, sollten diese Arbeiten nicht im Product Backlog geführt werden.
Lösung: Sorge für häufigere Releases
Alles, was dazu führt, dass Releases aufwändig sind oder selten stattfinden, wird als Hindernis für die Wertschöpfung betrachtet. Beide Hindernisse sollten beseitigt werden. Um dies zu erreichen, solltest du zunächst Transparenz schaffen. Organisiere eine Sprint Retrospektive zu diesem Thema und bespreche in der nächsten Retrospektive die Häufigkeit der Releases. Überlegt gemeinsam im Team: Was hindert uns daran, häufiger zu releasen?
Nach meiner Erfahrung kennen die Entwickler die Ursachen des Problems oft genau und haben bereits Vorschläge, wie man sie lösen kann. Dabei fallen mit großer Wahrscheinlichkeit Begriffe wie „Continuous Integration“, „Continuous Delivery“ oder „Testautomatisierung“.
Langfristig wird die Automatisierung des Releaseprozesses dazu führen, dass wiederkehrende Aufgaben nicht mehr im Product Backlog auftauchen.
4. Das Product Backlog dient nicht der Dokumentation von Verträgen
Ein typisches Szenario: Ein Unternehmen benötigt eine neue Software zur Verwaltung von Kundendaten und erstellt eine Ausschreibung. Im Lastenheft werden alle Anforderungen und Wünsche an die Software definiert. Es beschreibt, was erreicht werden soll und enthält Informationen zum Projektziel, den benötigten Funktionen, Zeit- und Budgetvorgaben sowie Qualitätsanforderungen.
Eine Agentur bewirbt sich auf die Ausschreibung und erstellt ein Pflichtenheft, das detailliert darlegt, wie die Anforderungen umgesetzt werden sollen – inklusive Methoden, Technologien und Lösungen für die beschriebenen Features.
Nachdem das Unternehmen die Agentur ausgewählt hat, geschieht oft Folgendes: Das Pflichtenheft wird als Product Backlog des Scrum-Teams übernommen. Das Problem dabei ist, dass das Product Backlog nun wie ein Vertrag behandelt wird.
Typischerweise sind Verträge statische Dokumente, die von Juristen erstellt werden und nur mit schriftlicher Genehmigung geändert werden dürfen. Ein Product Backlog hingegen ist dynamisch – es wird laufend vom Scrum-Team angepasst, um auf veränderte Anforderungen oder neue Erkenntnisse zu reagieren. Dieser Widerspruch zwischen der Flexibilität eines Product Backlogs und der Starrheit eines Vertragsansatzes führt häufig zu Problemen im agilen Entwicklungsprozess.
Lösung: Schließe agile Verträge ab
Es wird deutlich: Das Product Backlog ist nicht dafür gedacht, als Dokumentation für Features oder Verträge zu dienen. Wenn du jedoch in einer Situation bist, in der das Product Backlog als Vertrag interpretiert wird, besteht der erste Schritt darin, beide Vertragsparteien für diese Problematik zu sensibilisieren. Im klassischen Projektmanagement werden Änderungsanfragen oft als negativ betrachtet, da sie als Planungsfehler wahrgenommen und mit zusätzlichen Kosten verbunden werden. In Scrum hingegen bedeuten Änderungen Chancen und die Fähigkeit, die Software flexibel anzupassen, wird als Wettbewerbsvorteil angesehen.
Das Manifest für agile Softwareentwicklung betont dies auch:
„Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen.
Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“
Wenn du diesen Wettbewerbsvorteil nutzen möchtest, sollte das Ziel sein, von starren Festpreisverträgen zu flexibleren, „agileren“ Vertragsmodellen zu wechseln.
Ein bekanntes Beispiel für einen solchen Vertrag ist „Money for Nothing, Change for Free“. Bei „Change for Free“ kann der Kunde jederzeit Anforderungen ändern, hinzufügen oder streichen, solange die Arbeit daran noch nicht begonnen hat. Der Vertrag kann außerdem jederzeit gekündigt werden, wobei der Kunde dem Auftragnehmer 20 % der verbleibenden Vertragslaufzeit als Abfindung zahlt, ohne dass der Auftragnehmer weiter liefern muss. Dieses Modell bietet beiden Parteien Vorteile: Der Kunde spart Zeit und Geld, während der Auftragnehmer eine Abfindung erhält und die Suche nach einem neuen Projekt finanziell abgesichert ist.
Ich verstehe, dass ein Übergang von mehrjährigen Festpreisverträgen zu flexibleren Modellen eine große Umstellung darstellt. Ein möglicher Zwischenschritt könnte darin bestehen, nicht mehr Features, sondern Sprints zu einem festen Preis zu kaufen oder zu verkaufen.
Langfristig werden sich „agilere“ Vertragsmodelle nicht nur in Form eines schlankeren Product Backlogs, sondern auch in der verbesserten Agilität des gesamten Unternehmens auszahlen.
Ein langes Product Backlog ist ein Symptom
Diese vier häufigen Fehlverwendungen des Product Backlogs verursachen eine Überfüllung von Tasks, die den gesamten Entwicklungsprozess behindern und verlangsamen.
Wenn es dir gelingt, die Ursachen für einen übervollen Backlog in deinem Team zu identifizieren und die Fehlnutzung zu beseitigen, ist das Resultat weit mehr als ein kürzeres Product Backlog. Du sparst deinem Scrum-Team Zeit ein, die es nutzen kann, um sich auf die wesentlichen Dinge zu fokussieren.
Ryan Singer, der Gründer von Basecamp, hat dies schön auf den Punkt gebracht:
„Backlogs sind große Zeitfresser. Die Zeit, die damit verbracht wird, alte Ideen zu überprüfen, zu pflegen und zu organisieren, hält alle davon ab, sich mit den aktuellen Projekten zu befassen, die im Moment wirklich wichtig sind.“
Wenn du hier Bedarf siehst und mehr rund um das Backlog Management lernen möchtes, empfehle ich dir das zertifizierte Training der Scrum.org „Professional Scrum Product Backlog Management Skills™“ (PSPBM Skills). Termine und alle weiteren Informationen findest du auf der Beschreibungsseite.
Ich freue mich sehr, wenn wir uns dort treffen!
Bis dahin: Scrum on!
