Ein radikaler Ratschlag zum Product-Backlog-Management lautet:
Definiere ein Ziel für das Produkt. Lösche alle Einträge, die nichts damit zu tun haben. Beschränke die Anzahl der verbleibenden Einträge auf 30. So wird das Product-Backlog transparent.
Diesen Ratschlag höre ich oft von agilen Coaches. Er verkörpert das Wesen eines effektiven Product-Backlogs: eine kurze Liste von Funktionen, die das Erreichen des nächsten Ziels versprechen.
Doch was wird oft übersehen?
Das Product-Backlog ist ein Werkzeug zur Stakeholder-Kommunikation. Und die traurige Wahrheit über Stakeholder-Kommunikation? Sobald ein Scrum Team mehr als zwei Stakeholder hat, spielen Einfluss, Politik und Macht eine Rolle. In einer solchen Situation alle Einträge zu löschen, um Transparenz zu schaffen – auch wenn es vernünftig klingt –, wäre fatal. Deshalb zögern viele Scrum Teams, diesen Schritt zu tun.
Ein unstrukturiertes Product-Backlog ist jedoch in der Kommunikation mit Stakeholdern nutzlos.
Deshalb stelle ich dir im Folgenden 5 weniger radikale Methoden vor. Sie helfen dir, das Product-Backlog schrittweise transparenter zu gestalten. Langfristig verbessern sie die Kommunikation zwischen dem Scrum Team und den Stakeholdern.
Los geht’s:
Methode 1: Product-Backlog-Einträge mit Ansprechpartner versehen
Elon Musk, der CEO von Tesla, vertritt folgendes Prinzip für Anforderungen:
„Anforderungen müssen einer Person zugeordnet werden, nicht einem Team oder einer Abteilung. Die Person, die die Anforderung oder Rahmenbedingung definiert, muss damit einverstanden sein, dass sie die Verantwortung dafür übernimmt.“
Die Gründe dafür sind offensichtlich:
- Es wird nur entwickelt, was mindestens von einer Person gewünscht ist.
- Der Eintrag geht nicht in den Untiefen des Product-Backlogs verloren. Wenn er für eine Person wichtig ist, wird sie sich nach ihm erkundigen.
- Bei komplexer Umsetzung des Product-Backlog-Eintrags hat das Scrum Team jederzeit einen Ansprechpartner.
Wenn du Elons Prinzip umsetzen möchtest, mache dein Product-Backlog durch die Benennung von Ansprechpartnern transparenter. Nutze dazu folgende Fragen, um die Ansprechpartner zu finden:
- Wer sind die Nutzer des Produkts?
- Wer sind die potenziellen Nutzer des Produkts?
- Wer kauft das Produkt, wenn nicht die tatsächlichen Nutzer?
- Wer investiert in das Produkt?
- Wer unterstützt das Team bei der Erreichung seiner Ziele?
- Wer kennt sich mit der entsprechenden technologischen Landschaft aus?
- Wer kennt den Markt und die Geschäftssituation?
Die Antworten auf diese Fragen liefern dir eine Reihe von Stakeholdern für das Produkt. Betrachte jeden Product-Backlog-Eintrag einzeln und überlege, welchem Stakeholder er zugeordnet ist.
Und vergiss dabei nicht Elons Prinzip: Es sollte sich immer um eine reale Person handeln, damit das Team einen Ansprechpartner für Detailfragen hat.
Und das Beste zum Schluss:
Das Team weiß auch gleich, wer zum Sprint-Review eingeladen werden sollte, wenn der Product-Backlog-Eintrag fertiggestellt ist.
Methode 2: Product-Backlog-Einträge schneiden
Beschreiben Einträge im Product-Backlog einen zu großen Funktionsumfang, sind sie schwer zu verstehen.
Für Transparenz im Product-Backlog sollten die Einträge so formuliert sein, dass sie schnell verstanden werden können. Dafür müssen sie oft kleiner geschnitten werden.
Um die Einträge des Product-Backlogs zu zerschneiden, helfen folgende Fragen:
- Wenn wir diesen Eintrag des Product-Backlogs an nur einem Tag umsetzen müssten, worauf würden wir uns konzentrieren? Was könnte später in weiteren Product-Backlog-Einträgen erledigt werden?
- Was ist die kleinstmögliche und einfachste Möglichkeit, diesen Eintrag des Product-Backlogs zu implementieren?
- Welche Schritte durchlaufen die Benutzer, wenn sie die in diesem Eintrag beschriebenen Funktionen nutzen?
- Welche der Geschäftsregeln, die für diesen Eintrag wichtig sind, haben den geringsten Einfluss? Auf welche können wir vorerst verzichten und sie als weitere Product-Backlog-Einträge formulieren?
- Wie sehen die „Happy“- und „Unhappy“-Pfade für diesen Eintrag im Product-Backlog aus? Jeder Pfad kann ein eigener Product-Backlog-Eintrag sein.
- Auf welche der Akzeptanzkriterien für diesen Eintrag können wir vorerst verzichten und sie als weiteren Product-Backlog-Eintrag aufnehmen?
- Welche CRUD-Interaktionen (Create, Read, Update, Delete) haben die Nutzer mit diesem Product-Backlog-Eintrag?
Neben dem Zerschneiden von Product-Backlog-Einträgen erhöht das Hinzufügen von möglichem Wert und Umfang auch die Transparenz. Wie das geht, erkläre ich dir in der nächsten Methode:
Methode 3: Wert und Umfang schätzen
Schätzungen sollten immer in diesen beiden Dimensionen erfolgen:
- Wert
- Umfang
Insbesondere in dieser Reihenfolge. Erst den möglichen Wert und dann den Umfang schätzen. Warum? Die Größe eines Product-Backlog-Eintrags ist belanglos, wenn dieser wenig Wert verspricht. In dieser Situation wäre das Schätzen des Umfangs reine Zeitverschwendung für das Team. Zum Schätzen des möglichen Werts sollten die Stakeholder befragt werden, zum Schätzen des Umfangs die Entwickler.
Hier ein einfaches Vorgehen, wie du einen Schätz-Workshop anleiten kannst. Wir betrachten hier nur das Schätzen des Umfangs. Das Schätzen von Wert erfolgt ganz ähnlich.
Die Methode, die ich dir jetzt gleich erkläre, ist als „Wall Estimation“ bekannt und funktioniert folgendermaßen:
- Als relative Größeneinheiten verwenden wir T-Shirt-Größen. Die T-Shirt-Größen werden auf einer Wand in separaten Spalten aufgezeichnet.
- Ein Entwickler nimmt einen der zu schätzenden Product-Backlog-Einträge und liest ihn laut vor.
- Der Entwickler ordnet den Eintrag dann in die Spalte ein, die seiner Meinung nach den relativen Umfang dieses Eintrags am besten widerspiegelt, und gibt seine Gründe dafür an.
- Keiner der anderen Entwickler ergreift das Wort.
- Der Prozess wird fortgesetzt, wobei jeder Entwickler abwechselnd einen Product-Backlog-Eintrag platziert und seine Gründe dafür angibt, während der Rest des Scrum Teams zuhört.
- Wenn alle zu schätzenden Einträge platziert wurden, kann der Entwickler, der an der Reihe ist, einen bereits platzierten Eintrag verschieben. Hierbei muss er erneut seine Gründe dafür nennen.
- Wenn alle Einträge platziert wurden und alle Entwickler damit zufrieden sind, wo sie sich befinden, ist das Schätzen abgeschlossen.
Wall Estimation ist eine einfache Methode, um gleichzeitig Transparenz und Verständnis zu schaffen. Sie funktioniert sowohl für Wert als auch für Umfang.
Methode 4: Muster im Product-Backlog aufzeigen
Ist Produktentwicklung ein linearer Prozess?
Wenn wir die Entwicklung von Hardware-Produkten betrachten, dann ist diese Vorstellung sinnvoll. Wenn wir über Software-Produkte nachdenken, dann ist diese Vorstellung hinderlich. Der Vorteil von Software liegt darin, dass das Produkt mit den Bedürfnissen der Nutzer mitwachsen kann. Es verändert sich. Es passt sich an.
Aber nicht linear, sondern in Zyklen.
Diese Erkenntnis können wir auch im Management des Product-Backlogs nutzen. Wie geht das? Du kannst hierzu einen Ecocycle für das Produkt betrachten. Stelle dir dazu den Ecocycle als den Lebenszyklus einer Pflanze vor. Das Wachstum der Pflanze durchläuft unterschiedliche Phasen.
Nutze diese Analogie und teile die Einträge des Product-Backlogs den Phasen des Produktlebenszyklus’ zu. Aus meiner Erfahrung liefert diese Aktivität tiefere Einsichten über die Struktur des Product-Backlogs und offenbart Potenzial für Anpassungen. Etwa wenn wir dadurch erkennen, dass alle Einträge des Backlogs auf Features in der Reifephase einzahlen, aber wir keine Einträge haben, die die kreative Zerstörung von Features unterstützen.
Ein Appell: Wenn du diese Methode nutzt, setze sie nicht nur im Scrum Team ein. Lade die Stakeholder zum Workshop mit ein. Dann ist der Ecocycle eine effektive Methode, um den Austausch zwischen Stakeholdern und Scrum Team zu vertiefen.
Eine weitere Möglichkeit, einen strukturierten Ausblick für das Produkt zu geben, stellt die nächste Methode dar.
Methode 5: Einen Ausblick ermöglichen
Das größte Problem mit Roadmaps?
Sie werden oft als fester Plan missverstanden. Aus meiner Sicht geht es beim Roadmapping eher um die Kommunikation zwischen Scrum Team und Stakeholdern. Deshalb gefällt mir auch der Begriff „Roadmapping“ besser. Er hebt hervor, dass es eine Aktivität ist.
Damit Roadmapping die Kommunikation zwischen Stakeholdern und Scrum Team verbessert, solltest du einen sehr leichtgewichtigen Ansatz wählen. Hierzu verwende ich am liebsten die „Now, next, later“-Roadmap.
Die Einträge des Product-Backlogs, an denen das Scrum Team in diesem Sprint arbeitet, kommen dabei in die Spalte „Now“. Der Austausch mit den Stakeholdern geschieht zur Frage:
„Wohin kommen die anderen Einträge des Product-Backlogs?“
Wichtige Einträge sollten unter „Next“ fallen. Alle anderen Einträge kommen in die Spalte „Later“.
Dieses leichtgewichtige Roadmapping ermöglicht den einfachen Austausch zwischen Stakeholdern und Scrum Team und macht dadurch das Product-Backlog transparent.
Denn Transparenz bedeutet nicht nur Sichtbarkeit, sondern auch gemeinsames Verständnis.