Im Jahr 2016 war ich das erste Mal Product Owner.
Zu dieser Zeit befand sich das Team im zweiten Sprint. An meinem ersten Tag erhielt ich ein Product Backlog mit 142 Einträgen. Ich verbrachte zwei Wochen damit, die Einträge zu verstehen. Ich beschrieb sie und schätzte mit dem Team den Aufwand grob ab. Am letzten Tag des Sprints löschte ich dann alle Einträge.
Die Rückmeldung der Stakeholder im Sprint Review machte mir schmerzlich bewusst, dass die Produktentwicklung keinem geradlinigen Weg folgt. Es handelt sich nicht um einen Weg, bei dem wir bereits wissen, was wir als Nächstes tun werden. Softwareentwicklung gleicht eher einem in Nebel gehüllten Meer. Während wir rudern, erkennen wir langsam die Untiefen in der Nebelbank.
Diese Ungewissheit müssen wir bei der Entwicklung von Produkten in Kauf nehmen.
Wird diese Ungewissheit in deinem Team mit einem detaillierten Backlog versucht wegzudiskutieren? Dann ist dieser Artikel für dich geschrieben. Ich schildere dir vier Fehlvorstellungen, die über Product Backlogs kursieren. Ich bin in 10 Jahren Arbeit in Scrum Teams auf sie gestoßen. Diese Fehler hatten allesamt eines gemeinsam: Sie führten zu großen und damit unübersichtlichen Product Backlogs. Ferner gebe ich dir Tipps, wie du anfangen kannst, diese Fehler zu korrigieren.
Los geht's:
Fehler 1: Das Product Backlog ist eine Liste aller technischen Aufgaben
Das Scrum Rahmenwerk ist einfach:
- Das Product Backlog beschreibt das „Was“.
- Das Sprint Backlog beschreibt das „Wie“.
Eine klare Trennung der Arbeit hilft dem Product Owner. Er kann die Arbeit nach dem wahrscheinlich höchsten Wert für das Produkt ordnen. Gleichzeitig können die Entwickler die Arbeit nach technischen Gesichtspunkten im Sprint sortieren und festlegen, wann wer an was arbeitet. Enthält nun das Product Backlog technische Aufgaben, sind sowohl Product Owner als auch Entwickler in ihrer Arbeit behindert. Mehr noch: Da mehrere technische Aufgaben nötig sind, um einem Nutzer eine neue Funktion zu ermöglichen, wird das Product Backlog sehr groß und damit unübersichtlich.
Gleicht das Product Backlog einer Liste an technischen Aufgaben, dann haben mir in der Vergangenheit folgende Fragen geholfen, das Backlog zu verschlanken:
- Wer erhält das Ergebnis dieser Aufgabe?
- Was ermöglicht ihm dies?
Lautet eine technische Aufgabe etwa „Abfrage der Nutzerdaten aus der Datenbank“, dann könnte die Antwort auf die Fragen „Wer erhält das Ergebnis dieser Aufgabe?“ und „Was ermöglicht ihm dies?“ lauten: Ein Nutzer, der seine Profileinstellungen anpassen möchte.
Wie du sehen kannst, helfen diese beiden Fragen, aus technischen Aufgaben mögliche User Stories zu formulieren. Sie könnte lauten: „Als ‚häufiger Vertipper‘ möchte ich in den Profileinstellungen meinen Namen und meine Adresse korrigieren, damit die Bestellung an die richtige Adresse geschickt wird.“ Da für die Umsetzung dieser Story mehrere technische Aufgaben nötig sind, lassen sich technische Aufgaben einfach zu Stories gruppieren. Diese User Story beschreibt dann einen Eintrag im Product Backlog, und die einzelnen technischen Aufgaben bilden die Tasks im Sprint Backlog.
Durch die Nutzung dieser beiden Fragen verwandelst du die Liste aller technischen Aufgaben in ein Product Backlog!
Fehler 2: Das Product Backlog ist ein Werkzeug zur Koordination zwischen Teams
Wenn wir die Ungewissheit bei der Produktentwicklung in Kauf nehmen und akzeptieren, dass detaillierte Pläne die Ungewissheit nicht nehmen, wie können wir dann das Risiko minimieren?
Scrum bietet dazu zwei Hilfsmittel:
- Sprints: Ein fester Zeitrahmen, der die Investitionen des Unternehmens in ein Vorhaben begrenzt. Wenn ich von Investitionen spreche, meine ich die Kosten, die die Mitglieder des Teams dem Unternehmen verursachen.
- Scrum Team: Ein Scrum Team zeichnet sich dadurch aus, dass es interdisziplinär ist. Das bedeutet: In einem Scrum Team sind alle Fähigkeiten versammelt, um innerhalb eines Sprints eine neue Version des Produkts zu fertigen, welche den Qualitätsansprüchen des Unternehmens entspricht.
Sind mehrere Teams nötig, um eine neue Version des Produkts zu fertigen, ist das zunächst ein Problem.
Ein Beispiel, um dies zu verdeutlichen: Benötigt es ein Design- und ein Entwicklungsteam, um einen Eintrag abzuschließen, dann entstehen Abhängigkeiten zwischen den Teams. Dauert nun die Erstellung des Designs länger als erwartet, kann das Entwicklungsteam erst später anfangen. Dadurch steigt das Risiko, dass die Arbeit nicht innerhalb eines Sprints abgeschlossen wird. Das Unternehmen hat dadurch ein größeres finanzielles Risiko. Ursprünglich sollte nur in einen Sprint investieren werden. Jetzt fallen die Kosten eines zweiten Sprints an. Statt vier Wochen dauert es nun acht Wochen, bis die Kunden die neue Version des Produkts im Review beurteilen können. Abhängigkeiten zwischen Teams stellen somit ein finanzielles Risiko dar. Versuchen wir, diese Abhängigkeiten im Product Backlog zu verwalten, indem wir etwa Design- und Entwicklungseinträge erstellen und deren Abhängigkeit kenntlich machen, so verschwindet das Risiko dadurch nicht. Es besteht weiterhin und ist nur lediglich sichtbar gemacht worden. Wollen wir dieses Risiko endgültig eliminieren, dann benötigen wir interdisziplinäre Teams.
Um von einem Design- und Entwicklungsteam zu mehreren interdisziplinären Teams zu gelangen, hat mir in der Vergangenheit die Erstellung einer Fähigkeitenmatrix geholfen. Sie beschreibt, welche Fähigkeiten im Team nötig sind, um einen Eintrag nach der Definition of Done abzuschließen. Zudem macht sie transparent, welche Fähigkeiten im Team noch fehlen.
Hier findest du ein Beispiel einer solchen Matrix:
Das Product Backlog ist kein Koordinationswerkzeug. Es sollte nach Wert geordnet sein und nicht nach der Bearbeitungsreihenfolge.
Interdisziplinäre Teams machen dies möglich!
Fehler 3: Das Product Backlog ist ein Plan für das nächste Release
Das Product Backlog ist kein Releaseplan.
Ein Releaseplan beschreibt, welche Features bis wann freigegeben werden müssen und welche Aktivitäten dazu nötig sind. Häufig gleicht dieser Plan einer Checkliste mit vielen wiederkehrenden Aktivitäten, die bei jedem Release unternommen werden müssen:
- Die Versionsnummer ist vergeben.
- Release-Notes sind erstellt.
- Dokumentation für die Nutzer ist bereit.
- Support und Vertrieb ist geschult.
Releases sind im Scrum unabhängig von Sprints, und die Aktivitäten, die dafür nötig sind, finden sich in der Definition of Done wieder. Wenn Releases viele Aktivitäten und viel Aufwand bedeuten, dann sollten diese Arbeiten nicht im Product Backlog gesammelt werden. Mein Rat hier:
Es sollte häufiger released werden.
Alles, was dazu führt, dass Releases aufwändig sind, wird als Hindernis zur Lieferung von Wert gesehen. Das Gleiche gilt für alles, was dazu führt, dass Releases nicht häufig durchgeführt werden. Beide Hindernisse sollten beseitigt werden.
Willst du diese Hindernisse beseitigen, dann beginne damit, dieses Problem transparent zu machen. Führe eine Sprint Retrospektive zu diesem Thema durch. Mache die Häufigkeit der Releases zum Thema der nächsten Retrospektive. Überlegt gemeinsam im Team: Was hindert uns daran, häufiger zu releasen? Nach meiner Erfahrung kennen die Entwickler die Ursache des Problems und haben bereits Ideen, was verändert werden sollte. Ich würde sogar darauf wetten, dass mindestens einer der folgenden drei Begriffe fällt: Continuous Integration, Continuous Delivery oder Testautomatisierung.
Jetzt hast du einen Ansatz, wie du dieses Hindernis zusammen mit deinem Team angehen kannst. Langfristig wird die Automatisierung des Releaseprozesses dazu führen, dass das Product Backlog keine wiederkehrenden Aufgaben enthält.
Fehler 4: Das Product Backlog dient der Dokumentation von Verträgen
Ein typisches Szenario:
Ein Unternehmen benötigt eine neue Software zur Verwaltung seiner Kundendaten. Es wird eine Ausschreibung erstellt. Im Lastenheft werden alle Anforderungen und Wünsche an das Produkt beschrieben. Es legt dar, was erreicht werden soll, enthält allgemeine Informationen zum Projekt, zu den Zielsetzungen, den zu erfüllenden Funktionen, zeitlichen und finanziellen Rahmenbedingungen sowie Qualitätsanforderungen. Eine Agentur bewirbt sich auf diese Ausschreibung. Sie erstellt ein Pflichtenheft. Dieses beschreibt, wie die Anforderungen umgesetzt werden sollen. Es enthält spezifische Lösungswege, Methoden, Technologien und detaillierte Angaben zur Umsetzung jedes einzelnen Features aus dem Lastenheft. Das Unternehmen entscheidet sich für diese Agentur.
Und jetzt passiert das Unausweichliche:
Das Pflichtenheft wird zum Product Backlog des Scrum Teams. Somit repräsentiert das Product Backlog einen Vertrag.
Was zeichnet Verträge in der Regel aus? Es ist ein statisches Dokument, von Anwälten für Anwälte geschrieben und darf ohne schriftliche Genehmigung nicht verändert werden. Was zeichnet ein Product Backlog aus? Es ist dynamisch und wird ständig vom Scrum Team angepasst, wenn es die Umstände erfordern.
Wie du sehen kannst, eignet sich das Product Backlog nicht zur Dokumentation von Features oder Verträgen. Dafür ist es auch nicht gedacht!
Befindest du dich allerdings in dieser Situation, dann sollte dein erster Schritt sein, beide Vertragsparteien für die aktuelle Situation zu sensibilisieren. Im Projektmanagement wird ein Change-Request häufig als etwas Negatives gesehen. Änderungen werden als Fehler bei der Planung aufgefasst und verursachen deshalb zusätzliche Kosten. Nutzen wir Scrum, dann bedeuten Änderungswünsche neue Möglichkeiten und in der Lage zu sein, die Software anzupassen, einen Wettbewerbsvorteil.
So ist es auch im Manifest für agile Softwareentwicklung festgehalten:
„Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“
Wenn du Veränderungen als Wettbewerbsvorteil nutzen willst, sollte dein Ziel sein, weg von Festpreisverträgen hin zu „agileren“ Verträgen zu gelangen. Das bekannteste Beispiel eines agilen Vertrags ist „Money for Nothing, Change for Free“. „Change for Free“ bedeutet hier, dass der Kunde jede Anforderung ändern kann. Er kann auch Anforderungen hinzufügen oder löschen. Dies ist möglich, solange der Auftragnehmer noch nicht mit der Arbeit daran begonnen hat. Außerdem kann der Vertrag jederzeit beendet werden. In diesem Fall zahlt aber der Kunde dem Auftragnehmer 20 % der verbleibenden Vertragslaufzeit als Abfindung aus. Dafür muss der Auftragnehmer nichts mehr liefern. Diese Vertragsvariante ermöglicht es Unternehmen, Verträge häufiger vorzeitig zu beenden. Dadurch spart der Kunde Zeit und Geld. Für den Anbieter ist es vorteilhaft, weil er die Suche nach einem neuen Kunden bezahlt bekommt.
Ich bin mir bewusst, dass Vertragsänderungen eine große Umstellung bedeuten. Der Weg von einem mehrjährigen Festpreisvertrag zu einem „Money for Nothing, Change for Free“-Vertrag scheint weit zu sein. Ein erster Zwischenschritt könnte daher sein, nicht mehr Features, sondern Sprints zum Festpreis zu (ver-)kaufen. Ein Beispiel hierfür ist Amazing Outcomes. Dort kann das „Plug & Play- Scrum Team sprintweise beauftragt werden. Mehr dazu findest du hier.
Langfristig werden sich „agilere“ Verträge auszahlen. Und zwar nicht nur in einem kurzen Product Backlog, sondern in der Agilität des Unternehmens!
Ein langes Product Backlog ist nur ein SymptomUrsache dafür ist meist einer dieser vier Fehler.
Wenn du diese Fehler beseitigst, 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 lernen möchtest, wie du ein minimales Product Backlog erstellst, hätte ich einen Vorschlag: Du könntest mein nächstes „Professional Scrum Product Backlog Management“-Training besuchen. Zusammen erstellen wir ein Produkt-Ziel, schreiben Product-Backlog-Einträge und ich zeige dir, wie du sie nach Wert ordnen kannst.