Wie kann das Product Backlog verbessert werden?
Eine Frage, die sich nicht nur Product Owner stellen, sondern auch Scrum Master, die sie coachen. Ich beschäftige mich nun schon über zehn Jahre mit dem Management von Product Backlogs. Dabei bin ich zu einer Einsicht gelangt:
Eine Blaupause gibt es nicht.
(Wenn dir jemand so etwas verkaufen möchte, solltest du erstmal skeptisch sein.) Was mir jedoch in der Vergangenheit immer gut geholfen hat, war, Fragen zu stellen. So konnte ich Probleme rund um das Product-Backlog-Management aufzeigen und Verbesserungen anregen.
Hier findest du meine Top 7:
Frage 1: Hat das Product Backlog eine überschaubare Größe?
„Wie viele Einträge hat euer Product Backlog im Moment?“
Mit dieser Frage beginne ich jede meiner „Product Backlog Management Skills“-Schulungen. Von 10 bis 1000 Einträgen habe ich bestimmt schon jede Antwort gehört. Ja, du hast richtig gelesen: „1000“. Ich war auch sprachlos.
Ich denke, eine richtige Antwort auf die Frage gibt es nicht. Was es aber schon gibt, ist ein „Zuviel“. Zu Beginn meiner Karriere habe ich als Product Owner gearbeitet und damals waren einmal 142 Einträge im Product Backlog. Obwohl sich drei Teams daran bedienten, hat mir diese Erfahrung gezeigt, dass es ein Zuviel gibt. Ich selbst konnte nur noch eine Handvoll Einträge im Detail kennen. Rückfragen zu einzelnen Einträgen konnte ich auch nicht beantworten. Das große Ganze im Backlog zu erkennen, war nicht mehr möglich.
Kurzum: Ich konnte das Backlog nicht mehr überschauen.
Wenn du nicht die gleichen Fehler machen willst wie ich, solltest du dir als Product Owner die Frage stellen: Hat das Product Backlog eine überschaubare Größe?
Frage 2: Könnten einzelne Product-Backlog-Einträge verständlicher ausgedrückt werden?
Nicht jeder Eintrag des Product Backlog muss sich gleichen.
Product-Backlog-Einträge zu standardisieren kann bewirken, dass das Product Backlog überschaubarer wird. Alles als User Stories zu formulieren, wird aber sicherlich die Verständlichkeit vermindern.
Deshalb stelle dir die Frage:
„Könnten einzelne Product-Backlog-Einträge verständlicher ausgedrückt werden?“
Eine Möglichkeit, einzelne Einträge verständlicher auszudrücken, ist, das passende Format zu verwenden.
Hier drei bekannte Formate, die du nutzen kannst:
- User-Story: Als Typ von Nutzer möchte ich diese Aufgabe erfüllen, damit ich dieses Ziel erreichen kann.
- Job-Story: Wenn ich in dieser Situation bin, dann will ich diese Möglichkeit haben, damit ich das erhoffte Ergebnis erreichen kann.
- Hypothese: Wir glauben, dass dieses Feature zu diesem Ergebnis führen wird. Wir sind zuversichtlich, dass es gelingen wird, wenn wir ein messbares Signal sehen.
- Bug: Dieses Problem ist aufgetreten, als diese Schritte ausgeführt wurden. Allerdings wurde dieses Verhalten erwartet. Das geschah mit diesem Betriebssystem und Browser. Für weitere Details siehe angehängte Screenshots und Logs.
Die nächste Frage, die du dir stellen kannst, lautet:
Frage 3: Wird das Product Backlog nach den neuesten Erkenntnissen geordnet?
„Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden.“
So beschreibt es der Scrum Guide. Besonderes Augenmerk sollten wir hier auf das Wort „emergent“ legen. Es bedeutet, dass sich das Product Backlog weiterentwickelt. Nochmal in anderen Worten ausgedrückt:
Wenn sich neue Erkenntnisse über das Produkt ergeben, dann sollte sich dies im Product Backlog widerspiegeln. Die Reihenfolge der Einträge sollte entsprechend geändert werden.
Hier vier Skalen, die du bei der Ordnung der Einträge des Product Backlogs in Betracht ziehen kannst:
- Größe: Einträge reichen von vagen Ideen, die noch mehr Verfeinerung benötigen, bis zu kleinen Einträgen, die bereit für das Sprint Planning sind.
- Wert: Einträge reichen von solchen mit unbekanntem Wert oder winzigen Änderungen bis zu Einträgen, die hohe Verzögerungskosten, Kundenanforderungen oder ROI versprechen.
- Risiken: Einträge reichen von geringen Risiken bei der Umsetzung bis hin zu hohen technischen Machbarkeitsproblemen, Abhängigkeiten von anderen Teams oder Drittparteien.
- Lernen: Einträge reichen von denen, für die es bereits einen Nachweis für ihren Wert gibt, bis hin zu denen, deren Wert noch unbekannt ist und durch Experimente oder Tests nachgewiesen werden muss.
Eine Empfehlung für die Ordnung des Product Backlogs von mir:
Die folgenden Product-Backlog-Einträge sollten oben im Product Backlog angeordnet werden: Die Einträge sollten klein und von hohem Wert sein. Sie sollten zudem ein angemessenes Risiko und ein hohes Lernpotenzial aufweisen.
Frage 4: Werden technische Schulden im Product Backlog aufgeführt?
Enthält das Product Backlog auch technische Schulden?
Bist du dir unsicher, was der Begriff „technische Schuld“ bedeutet? Ich erkläre es immer am Beispiel Kochen. Angenommen, du hast viele Gäste bei dir zu Hause. Einige Gäste essen kein Fleisch. Jemand anderes verträgt keinen Pfeffer und die Kinder wollen unbedingt Wiener Schnitzel mit Pommes. Natürlich möchtest du auch eine Vorspeise und eine Nachspeise servieren. Das gehört ja schließlich zu einer guten Party dazu. Zusammengefasst:
Du musst also mehrere Gänge und mehrere Speisen nacheinander zubereiten.
Was passiert, wenn du nach dem ersten Gang die Töpfe und Pfannen nicht abspülst? Welche Auswirkung kann es haben, wenn du die Messer nicht schleifst? Ist es ein Problem, wenn du die benutzten Teller der Vorspeise nicht abräumst und spülst?
Bei deiner Dinner-Party wird es dazu führen, dass die nächsten Gänge länger in der Zubereitung brauchen. Die Gäste müssen länger warten als angekündigt. Denn irgendwann musst du die Töpfe säubern, wenn du sie wiederverwenden willst. Du musst die Messer schleifen, bevor du das Rindfleisch in hauchdünne Scheiben schneiden kannst. Du wirst die benutzten Teller vom Tisch abräumen müssen, bevor du den nächsten Gang servieren kannst. Was hat das nun mit technischen Schulden zu tun?
In der Softwareentwicklung nennen wir diese Verzögerungen, die deine Vorhersagen, wann Features fertig sein werden, verfälschen, technische Schulden. Schulden, weil du sie aufnehmen kannst, um kurzfristig schneller zu sein. Aber langfristig wirst du nicht darum herumkommen, sie zurückzuzahlen.
Technische Schulden lassen sich häufig nicht vermeiden.
Aber wenn du langfristig deine Lieferzusagen und Releasetermine einhalten willst, solltest du sie im Product Backlog transparent machen. Außerdem solltest du sie regelmäßig zurückzahlen. Plane dafür auch diese Einträge im Sprint Planning ein.
Frage 5: Gibt es regelmäßige Refinements der Backlog-Einträge mit den Entwicklern und Fachexperten?
Wirf mal einen Blick in deinen Kalender.
Finden sich dort Termine mit der Aufschrift „Refinement“? Wenn nicht, solltest du das ändern. Refinements der Einträge des Product Backlogs sind unerlässlich, wenn du die Transparenz des Product Backlogs verbessern willst.
Wen solltest du einladen? Müssen immer alle Entwickler anwesend sein? Was ist mit Fachexperten?
Zu diesen Fragen habe ich mir vor einiger Zeit einmal ausführlich Gedanken gemacht. Du findest meine ausführlichen Antworten in diesem Artikel.
Die Kurzfassung findest du in diesem Bild:
Durch Refinement-Aktivitäten werden die Einträge des Product Backlogs von vagen Ideen in kleine Einträge überführt. Diese Einträge sind bereit für den nächsten Sprint. Zu Beginn solltest du eher Kunden und Stakeholder einbeziehen. Je näher wir der Umsetzung der Ideen kommen, desto mehr solltest du auch die Entwickler einladen.
Wenn du dir bereits Gedanken zu Refinements machst, dann solltest du dir auch diese Frage stellen:
Frage 6: Ist das Product Backlog für die Stakeholder sichtbar?
Was bedeutet Transparenz in Scrum?
Sprechen wir von Transparenz, dann meinen wir Sichtbarkeit und gemeinsames Verständnis. Gemeinsames Verständnis stellen wir mit Refinement-Aktivitäten her. Bleibt noch die Frage nach der Sichtbarkeit.
„Ist das Product Backlog für die Stakeholder sichtbar?“
Hier sollten wir Stakeholder eingrenzen. Wahrscheinlich wollen wir nicht, dass unsere Mitbewerber jedes geplante Feature unseres Produkts kennen.
Für welche Stakeholder das Product Backlog hingegen sichtbar sein sollte, hierzu gibt uns der Scrum Guide eine Empfehlung:
„Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen.“
Somit sollte das Product Backlog mindestens für das Scrum Team und die Kunden des Produkts sichtbar sein.
Hier zwei Beispiele, wie du deinen Kunden das Product Backlog sichtbar machen kannst:
Nachdem du einen Blick auf die öffentlichen Backlogs geworfen hast (die „Explore“-Spalte finde ich besonders nachahmenswert), kommen wir zur letzten Frage für heute:
Frage 7: Spiegeln sich die Wünsche aller Beteiligten im Product Backlog wider?
Hast du vorschnell auf diese Frage mit „Ja“ geantwortet?
Dann sollten wir reden. Ich bin hierbei nämlich anderer Meinung. Im Product Backlog sollten sich eben nicht die Wünsche aller Stakeholder widerspiegeln. Dies unterscheidet das Product Backlog von einem Arbeitsspeicher für ein Team.
Das Produkt existiert zu einem bestimmten Zweck. Alles, wovon wir glauben, dass es uns hilft, den Zweck besser zu erfüllen, sollte Bestandteil des Product Backlogs sein. Alles andere nicht.
Wie verwandelst du einen Arbeitsspeicher in ein Product Backlog?
Du musst lernen, Nein zu sagen. Wenn dir das noch nicht so leichtfällt und du dabei Unterstützung suchst, dann besuche unser „Professional Scrum Product Owner – Advanced“-Training. Unter der Anleitung von Peter Götz und mir kannst du dort diese Fähigkeit üben.