Das Management des Product Backlogs ist eine wichtige Fähigkeit für Product Owner.
Ein gut verwaltetes Product Backlog
- begrenzt die Erwartungen der Stakeholder bezüglich dessen, was das Produkt in Zukunft enthalten wird und was nicht.
- fokussiert die Anstrengungen der Entwickler in einem Sprint auf die Lieferung nutzbarer Software.
- hilft dem Scrum Team, sich auf ein gemeinsames Ziel zu konzentrieren und mehr Wert für die Kunden zu schaffen.
Somit öffnet ein gut verwaltetes Product Backlog die Tür für gute Zusammenarbeit zwischen Product Owner, Entwicklern und Stakeholdern.
Doch was geschieht, wenn das Management schlecht ist?
Ein schlecht verwaltetes Product Backlog birgt das Risiko, dass die Stakeholder und das Scrum Team unterschiedliche Erwartungen an das Produkt haben. Wenn Stakeholder und Scrum Team aneinander vorbeireden, kann das Product Backlog leicht einer endlosen Wunschliste für das Produkt gleichen. Im schlimmsten Fall investiert das Scrum Team viel Zeit in das Refinement und die Entwicklung von Product-Backlog-Einträgen, die der Kunde am Ende gar nicht wollte. Im besten Fall führt diese lange Wunschliste dazu, dass der Product Owner sie schwer priorisieren kann, die Entwickler sie schwer umsetzen können und die Stakeholder sie schwer verstehen können.
Es gibt viele Gründe für ein schlecht verwaltetes Backlog.
Ein Grund könnte sein, dass Scrum Teams zu fortgeschrittene Methoden nutzen, um die Einträge im Product Backlog zu verwalten. Diese Methoden mögen in der Theorie Erfolg versprechen, sind aber in der Praxis oft sehr kompliziert umzusetzen und daher zeitintensiv. Vielen Teams fehlt schlichtweg die Zeit, diese komplexen Methoden auf jeden Eintrag anzuwenden. Ein weiterer Grund könnte sein, dass manche Teams gar keine Werkzeuge zur Verwaltung des Backlogs nutzen.
Zwischen der Verwendung von fortgeschrittenen und gar keiner Methode besteht eine Lücke.
Dieser Artikel schließt diese Lücke, indem er dir sechs einfache Werkzeuge vorstellt, die dir helfen werden, ein erstes Product Backlog für ein Produkt zu erstellen oder dein aktuelles Backlog zu verwalten.
Sie lauten:
- Produkt-Ziel formulieren
- Modellierung von Nutzerrollen
- Beschreibung von Product-Backlog-Einträgen
- Aufwandbestimmung von Einträgen im Product Backlog
- Product-Backlog-Einträge aufteilen
- Anordnen von Einträgen im Product Backlog
Bevor wir die Werkzeuge im Detail besprechen, ein kurzer Hinweis:
Wenn du nach fortgeschrittenen Methoden suchst, dann wirf einen Blick auf die folgenden Artikel. In diesem Artikel konzentrieren wir uns auf die Grundlagen!
- Produktentdeckung gestalten: Einführung in das Lean UX Canvas
- Product Backlog Refinement: 5 konkrete Strategien für diese essenzielle Product-Management-Aktivität
- 5 Frameworks zur Wertquantifizierung, die unter erfahrenen Produktmanagern weitverbreitet sind
- 3 schockierende Probleme mit User Stories, die jeder Product Owner unbedingt vermeiden sollte
Los geht's mit dem ersten Werkzeug:
Werkzeug 1: Produkt-Ziel formulieren
Die Entwicklung eines Produkts verfolgt immer einen Zweck.
Diesen Zweck solltest du beim Management des Product Backlogs niemals aus den Augen verlieren. Scrum Teams halten diesen Zweck in Form eines Ziels für das Produkt fest. Das Ziel beschreibt, „wozu“ das Produkt entwickelt oder betrieben wird. Stelle dir das Produkt-Ziel als Zwischenziel oder einen Schritt vor, der deinem Scrum Team hilft, zu lernen und Fortschritte auf dem Weg zu einer Vision für das Produkt oder einem strategischen Ziel des Unternehmens zu machen.
Ein einfaches Format, wie du ein Ziel für das Produkt formulieren kannst, lautet:
Wir wollen [das Produkt oder die Dienstleistung] so verbessern, dass unsere Kunden erfolgreicher sind, wenn es darum geht, [ihr Problem zu lösen], wie durch [diese messbaren Veränderungen im Kundenverhalten] bestimmt.
Neben der Richtung, die das Produkt einschlagen soll, und der Möglichkeit, Fortschritte auf diesem Weg zu messen, liefert das Produkt-Ziel Kontext für Einträge des Product Backlogs.
Werkzeug 2: Modellierung von Nutzerrollen
Selbst erfahrene Product Owner machen diesen Fehler:
Nachdem sie das Ziel für das Produkt formuliert haben, widmen sie sich sofort den Funktionen und Features, die das Produkt enthalten soll. Sie springen vom „Wozu“ direkt zum „Was“ und vergessen dabei das „Wer“. Die Einstellung „Wenn wir es gebaut haben, werden die Nutzer es schon nutzen“ ist sehr gefährlich. Sie führt schnell zu Funktionen im Produkt, die niemand verwendet.
Deshalb solltest du dich als Nächstes fragen:
Wer soll das Produkt nutzen?
Ein einfaches Werkzeug, um diese Frage zu beantworten, ist die Modellierung von Nutzerrollen. Mit diesem Werkzeug werden die Rollen kategorisiert, welche die Benutzer bei der Interaktion mit dem Produkt einnehmen. Erst wenn das Scrum Team die Rollen kennt, kann es sich Gedanken darüber machen, wie unterschiedliche Rollen die Nutzung des Produkts beeinflussen. Die Modellierung von Nutzerrollen liefert mehr Kontext, um Einträge im Product Backlog zu erstellen und zu detaillieren, insbesondere wenn sie als User Stories formuliert werden sollen. Führe deshalb regelmäßige Brainstorming-Sessions mit dem Scrum Team und den relevanten Stakeholdern durch, um Rollen von Benutzern zu modellieren.
Du kannst dabei so vorgehen:
- Überlegt gemeinsam, welche Rollen die Benutzer bei der Nutzung des Produkts einnehmen.
- Führt ein Brainstorming durch, um eine erste Liste von Benutzerrollen aufzuschreiben.
- Gruppiert die unterschiedlichen Rollen thematisch.
- Beschreibt die übergeordneten Nutzergruppen detailliert.
Eine konkrete Anleitung für einen solchen Workshop kannst du hier nachlesen.
Werkzeug 3: Beschreibung von Product-Backlog-Einträgen
Nach dem „Wozu“ und dem „Wer“ folgt das „Was“.
Hast du den Workshop zur Modellierung von Nutzerrollen durchgeführt, solltest du nun eine Liste von Rollen vorliegen haben. Jetzt gilt es zu beschreiben, welche Handlung diese Rollen mit dem Produkt durchführen möchten.
Es gibt viele Möglichkeiten, um Features, Bugs, Hypothesen, Anforderungen und User Stories zu beschreiben. Da die bekannteste Form wohl User Stories sind, möchte ich dir die dahinterstehende Idee erläutern.
Wenn du die Einträge des Product Backlogs als User Stories festhältst, kannst du dieses Format verwenden:
Als [Rolle des Nutzers] möchte ich [etwas mit dem Produkt tun], um [ein bestimmtes Problem zu lösen oder einen Vorteil zu erhalten].
Der Begriff „User Stories“ geht auf Kent Beck zurück.
Kent war inspiriert von der Art und Weise, wie Nutzer manchmal begeistert von den neuen Funktionen eines Produkts erzählen:
„Ich gebe die Postleitzahl ein und die Software füllt automatisch Stadt und Bundesland aus, ohne dass ich eine Taste drücken muss!“
Seine Erkenntnis: Anstatt Geschichten darüber zu erzählen, was die Software nach dem Kauf leistet, warum nicht Geschichten formulieren, bevor die Software überhaupt geschrieben wird. Deshalb bezeichnete Kent sie als „Stories“, weil sie beschreiben, wie das Produkt verwendet wird. Es geht nicht primär um den geschriebenen Text, sondern um die erzählte Geschichte.
Denn die Kommunikation von Produktdetails über ein Dokument ist oft unzureichend. Selbst wenn alle im Team das gleiche Dokument gelesen haben, hat jeder oft eine unterschiedliche Vorstellung davon.
Wenn wir eine Geschichte hören, entstehen in unseren Köpfen Bilder, wie wir uns die Situation vorstellen. Diese Bilder sind es, über die sich Product Owner, Entwickler und Stakeholder austauschen sollten. Bei User Stories geht es darum, dass jeder sein Verständnis in Worten und Bildern ausdrückt und die Ideen so lange kombiniert und verfeinert werden, bis ein gemeinsames Verständnis entsteht.
Zusammengefasst: User Stories dienen als Erinnerungen an Gespräche, die wir im Team und mit Stakeholdern geführt haben oder noch führen müssen.
Werkzeug 4: Aufwandbestimmung von Einträgen im Product Backlog
Einträge können neben der Beschreibung noch viele weitere Attribute enthalten.
Zum Beispiel den Typ des Eintrags. Dabei könnte es sich bei einem Eintrag um ein Feature des Produkts oder um einen Fehler handeln. Ein Attribut ist jedoch von besonderer Bedeutung: Der Aufwand des Eintrags. Der Aufwand hilft zum einen zu bestimmen, ob der Eintrag innerhalb eines Sprints erledigt werden kann, und unterstützt zum anderen den Product Owner, die Kosten für die Umsetzung dieses Eintrags zu berücksichtigen.
Es gibt verschiedene Techniken, die Scrum Teams verwenden können, um den Aufwand der Einträge im Product Backlog zu bestimmen:
- Absolut: Oft zeitbasiert, z. B.: „Dieser Eintrag wird 7 Stunden Arbeit erfordern“.
- Relativ: Verwendet eine Skala, die es den Entwicklern ermöglicht, die Größe der Einträge im Verhältnis zueinander abzuschätzen. Beispiele hierfür sind Story Points oder T-Shirtgrößen.
- Right Sizing: Identifiziert Elemente, die klein genug sind, um innerhalb eines einzigen Sprints abgeschlossen zu werden. Hierbei diskutieren die Entwickler, ob sie einen Eintrag gemäß ihrer Definition of Done bequem innerhalb eines Sprints abschließen können. Wenn nicht, sollten sie den Eintrag aufteilen.
Wichtig: Da die Entwickler diejenigen sind, die die Arbeit verrichten, sind sie auch für die Bestimmung des Aufwands verantwortlich.
Ein einfaches Werkzeug, um den relativen Aufwand von Product-Backlog-Einträgen zu bestimmen, ist Planning Poker. Dies geht auf James Grenning zurück. Ich erwähne es hier, weil es besonders geeignet ist, dem Team zu helfen, ein gemeinsames Verständnis über den Aufwand der Arbeit zu erlangen.
Das Prinzip lehnt sich an eine Pokerrunde an. Konkret geht man wie folgt vor:
- Der Product Owner stellt den zu schätzenden Eintrag im Product Backlog vor und erklärt diesen bei Bedarf.
- Jeder Entwickler schätzt individuell den Eintrag, indem er ihm eine Größe zuordnet. Seine Wahl bleibt so lange verdeckt, bis alle geschätzt haben. Danach zeigen alle beteiligten Entwickler gleichzeitig ihre Wahl.
- Gibt es keine Übereinstimmung bezüglich der Größe des Product-Backlog-Eintrags, diskutieren die Entwickler mit den höchsten und niedrigsten Schätzungen ihre Einschätzungen. Danach wird dieser Eintrag von allen erneut geschätzt (Schritt 2). Dieser Schritt wird so lange wiederholt, bis eine Einigung erzielt wird. Diese Einigung spiegelt das gemeinsame Verständnis über den Product-Backlog-Eintrag wider.
Werkzeug 5: Product-Backlog-Einträge aufteilen
Einträge im Product Backlog, die mehr Arbeitsaufwand als ein Sprint darstellen, müssen aufgeteilt werden.
Allgemein sollten die Einträge im Product Backlog, die im nächsten Sprint in Betracht gezogen werden, immer deutlich weniger Aufwand als ein Sprint darstellen. Kleine Einträge sind einfacher zu verstehen, ermöglichen schnelleres Feedback, laden zur Zusammenarbeit ein und sind in der Regel schneller zu implementieren.
Hierbei sollte die Arbeit niemals nach Aktivitäten (wie Backend und Frontend, oder Entwicklung und Test) aufgeteilt werden, sondern immer nach Funktionalität, die noch von einem Anwender nutzbar ist. Mit anderen Worten: Wenn der Eintrag des Product Backlogs ein Tortenstück wäre, dann sollte man das Stück nicht horizontal (Boden, Füllung, Topping) zerschneiden, sondern vertikal. Niemand möchte nur den Tortenboden essen, sondern ein Stück der ganzen Torte, auch wenn es nur sehr schmal ist.
Hier sind zwei Vorgehensweisen, die du wählen kannst, um Product-Backlog-Einträge aufzuteilen:
1. Product-Backlog-Einträge nach Workflowschritten zerkleinern
Beinhalten Product-Backlog-Einträge einen Arbeitsablauf, können diese in einzelne Schritte zerlegt werden.
Der Eintrag, welcher beschreibt, dass ein Kunde die Waren in seinem Warenkorb bezahlen kann, lässt sich in folgenden Einträgen aufteilen:
- Als Kunde kann ich mich mit meinem Konto anmelden.
- Als Kunde kann ich meine Bestellung bezahlen.
- Als Kunde erhalte ich eine Bestätigungs-E-Mail zu meiner Bestellung.
2. Product-Backlog-Einträge in Happy- und Unhappy-Pfad zerkleinern
Eine Funktionalität beinhaltet häufig einen Happy-Pfad und einen oder mehrere Unhappy-Pfade. Der Happy-Pfad beschreibt, wie sich die Funktionalität verhält, wenn alles wie gewünscht verläuft. Gibt es Abweichungen, Ausnahmen oder andere Probleme, wird der Unhappy-Pfad aufgerufen.
Der Product-Backlog-Eintrag, welcher beschreibt, dass sich der Kunde mit seinem Konto anmelden kann, kann so in zwei Teile aufgeteilt werden:
- Als Kunde kann ich mich mit meinem Konto anmelden. Dies beschreibt den Happy-Pfad.
- Als Kunde kann ich mein Passwort zurücksetzen, wenn die Anmeldung fehlschlägt. Dies beschreibt den Unhappy-Pfad.
Weitere Möglichkeiten sind hier übersichtlich dargestellt.
Werkzeug 6: Anordnen von Einträgen im Product Backlog
Ein Product Backlog ist erst ein Product Backlog, wenn die Einträge geordnet sind.
Die Werkzeuge 1 bis 5 liefern uns viele Product-Backlog-Einträge und Informationen über ihre Wichtigkeit. Es fehlt noch, die Einträge zu ordnen, also eine Reihenfolge zu bestimmen, in der niemals zwei Einträge gleich wichtig sind.
Um diese Reihenfolge zu bestimmen, ist es hilfreich, die Einträge zu priorisieren.
Ein einfaches Werkzeug hierfür ist eine Aufwand-Nutzen-Matrix.
Die Matrix besteht aus zwei Achsen:
- Nutzen: Beschreibt den potenziellen Nutzen, den die Umsetzung eines Product-Backlog-Eintrags liefert.
- Aufwand: Beschreibt den möglichen Aufwand, den die Umsetzung eines Product-Backlog-Eintrags bedeutet.
Zur Priorisierung der Einträge werden die Einträge in die Matrix einsortiert.
Der Aufwand des Product-Backlog-Eintrags ergibt sich aus Schritt 3 „Aufwandbestimmung“. Der Nutzen des Product-Backlog-Eintrags kann aus unterschiedlichen Gesichtspunkten betrachtet werden. Deshalb sollten beim Bewerten unbedingt Stakeholder miteinbezogen werden.
Bewertungskriterien könnten sein:
- Umsatzpotential: Kann die Umsetzung des Product-Backlog-Eintrags zu erhöhten Einnahmen führen?
- Kundenzufriedenheit: Verbessert die Umsetzung des Product-Backlog-Eintrags die Benutzererfahrung oder löst ein dringendes Kundenproblem?
- Strategische Bedeutung: Wie sehr trägt die Umsetzung des Product-Backlog-Eintrags zum Erreichen des Produkt-Ziels bei?
Wenn alle Einträge in die Matrix einsortiert sind, können die Einträge im Product Backlog angeordnet werden:
- Hoher Nutzen, niedriger Aufwand: Diese Einträge sollten oben im Product Backlog angeordnet werden.
- Hoher Nutzen, hoher Aufwand: Bevor diese Einträge umgesetzt werden können, müssen sie weiter zerkleinert werden. Siehe Werkzeug 5. Die Einträge sollten in der Mitte des Backlogs einsortiert werden.
- Niedriger Nutzen, niedriger Aufwand: Diese Product-Backlog-Einträge können umgesetzt werden, sollte sich nichts Wertvolleres im Product Backlog befinden. Die Einträge sollten deshalb weiter unten im Backlog angeordnet werden.
- Niedriger Nutzen, hoher Aufwand: Diese Einträge sollten verworfen werden.
Die Verwaltung des Product Backlogs ist eine wichtige Fähigkeit, die dem Scrum Team hilft, effektiver an seinem Produkt zu arbeiten und Mehrwert zu liefern. Die sechs Werkzeuge helfen dir beim Product-Backlog-Management oder beim Erstellen eines ersten Product Backlogs. Falls du mehr darüber erfahren oder die Werkzeuge in der Anwendungen kennenlernen willst, dann habe ich eine Ankündigung zu machen:
Ankündigung: Scrum.org hat heute ein neues Skill-Training gelauncht!
Falls du dich bisher wenig mit dem Product-Backlog-Management beschäftigt hast und praktische Techniken zur Erstellung, Verfeinerung und Ordnung des Product Backlogs erlernen möchtest, dann lege ich dir den Besuch dieses Trainings ans Herz.
Hier findest du weitere Details zum „Professional Scrum Product Backlog Management Skills“-Training.
Es handelt sich um den Grundlagenkurs im Product-Backlog-Management – speziell für alle, die nach Wegen suchen, das Product Backlog transparenter zu gestalten, die Bedürfnisse von Stakeholdern zu erfassen und effektiver mit Stakeholdern zu kommunizieren.