Das Product Backlog und Werkzeuge zur Priorisierung

Jede agil arbeitende Organisation, egal ob Start-up mit zehn Mitarbeitern oder Konzerne und Behörden mit mehreren tausend, ob in der Softwareentwicklung, im Marketing oder im Personalbereich, steht vor der Herausforderung, die anstehenden, aus verschiedensten Richtungen und Interessensbereichen kommenden Aufgaben zu priorisieren.

Dabei steht uns meist die natürliche, menschliche Unfähigkeit zur Priorisierung sowie die Angewohnheit vieler Organisationen im Weg, möglichst alle laufenden und offenen Initiativen aus politischen Gründen als „gleichwichtig“ und mit „Prio A+++“ zu behandeln.

Mit diesem Verhalten verspielen wir allerdings die Chance, all unsere Energie und unseren Fokus auf das Thema zu lenken und konzentrieren, das uns, unseren Kunden und unserer Organisation den meisten Nutzen bringt, und diesen so bald wie möglich einstreichen zu können. Stattdessen arbeiten wir an allen Themen gleichzeitig und gefühlt wird keines davon jemals fertiggestellt.

Vor eben diesen Problemen standen wir zum Beispiel in unserem internen Projekt zum Aufbau eines prozessgesteuerten Qualitätsmanagementportals zur Erfüllung der ISO 9001:2015. Welche Methoden und Werkzeuge uns dabei geholfen haben und bei unserer Arbeit mit unseren Kunden helfen, diese Herausforderungen zu meistern, möchte ich im Folgenden etwas näher beleuchten.

Product Backlog?

Agile Methoden im Allgemeinen und Scrum im Speziellen verwenden das sogenannte Product Backlog zur Organisation und Priorisierung der Arbeit. Dabei stehen alle bekannten Aufgaben im Kontext des zu entwickelnden Produktes („Product Backlog Items“ oder kurz PBI) in einer priorisierten Liste.

Diese Liste, das Product Backlog, hat aber nicht etwa den Anspruch einer vollständigen Auflistung jeglicher To-dos bis ins kleinste Detail, sondern ist im Gegenteil ein Werkzeug zur Maximierung der nicht getanen Arbeit.

Nur die PBIs, die als wichtig erachtet werden und daher weit oben im Backlog stehen, werden soweit bearbeitet (analysiert, heruntergebrochen und beschrieben), dass sie für die Umsetzung bereit sind. Die restlichen PBIs stehen in deutlich gröberer Form am Ende des Backlogs. So wird sichergestellt, dass nur in jene PBIs Aufwand zur Vor- und Aufbereitung investiert wird, bei denen klar ist, dass sie auch in absehbarer Zeit zur Umsetzung anstehen. 

Über den Wolken oder: Auf welcher Flughöhe bin ich unterwegs?

Bevor wir mit dem Priorisieren beginnen, müssen wir uns über die Flughöhe bzw. den Kontext im Klaren sein, in der wir dies tun.

Gerade in größeren Organisationen, in denen mehrere Produkte/Projekte oder Initiativen parallel in Angriff genommen werden sollen, ist es essentiell, auch diese gegeneinander zu priorisieren. Erfahrungsgemäß stehen stets mehr Themen an, als Kapazität zur Umsetzung vorhanden ist. Umso wichtiger ist es, die wichtigsten anzugehen und fertigzustellen, bevor neue begonnen werden. Frei nach dem Motto: „Stop starting, start finishing.“

Sind die Produkte/Projekte priorisiert, betrachten wir die Ebene darunter, die Features. Dabei überlegen wir uns, welche Features/Funktionalität unser Produkt wirklich benötigt, um einen Nutzen beim Kunden zu generieren. Auch hierbei gilt wieder: Wir maximieren die nicht getane Arbeit, indem wir Features definieren, die alleinstehend einen Nutzen für unseren Markt/unsere Kunden oder die Organisation liefern. So können wir nach jedem gelieferten Feature feststellen, ob wir das Ziel, das wir mit dem Produkt/Projekt verfolgen, schon (ausreichend) erreicht haben und entscheiden entweder das nächste Feature umzusetzen oder zum nächsten Thema überzugehen.

Auf der letzten Ebene werden die Features dann in umsetzbare Happen zerlegt. In der Softwareentwicklung arbeitet man üblicherweise mit User-Storys. Hier gilt dasselbe Prinzip wie weiter oben beschrieben, wir priorisieren potentiell auslieferbare Bestandteile unseres Produktes und prüfen nach der Fertigstellung, ob das zugrunde liegende Ziel erreicht ist.

Wann muss ich priorisieren?

Die einfache Antwort auf diese Frage ist: Immer dann, wenn es notwendig ist.

Die Stärke von agilen Vorgehensmodellen liegt darin, flexibel und kurzfristig auf Veränderungen zu reagieren. In einem volatilen, schnelllebigen Umfeld können sich Kundenbedürfnisse und Rahmenbedingungen jederzeit ändern oder neue Themen aufkommen. Die Auswirkungen dieser Veränderungen zeitnah zu beurteilen und die Priorisierung, wenn nötig, anzupassen, ist ein Schlüssel um sicherzustellen, dass die vorhandene Energie und Kapazität weiterhin in die wichtigsten Themen investiert werden.

Schnitt der PBI und Emergenz des Backlogs

Hilfreich für das Erreichen einer Priorisierbarkeit des Backlogs ist ein sinnvoller Schnitt der PBI. Ein gutes Product Backlog Item ist so geschnitten, dass es auch alleinstehend auslieferbar ist und einen Wert erzeugt. Mit diesen in sich geschlossenen PBI und den damit verbundenen Werten ist dann das Priorisieren dieser gegeneinander möglich.

Je intensiver wir uns mit dem Schneiden und Bewerten des Backlogs beschäftigen, desto mehr Vorgänge werden wir generieren: Beim Ausarbeiten großer PBIs werden wir feststellen, dass diese wiederum in kleinere, alleinstehende Vorgänge gesplittet werden können. Dabei spricht man von einem emergenten Backlog.

Aber wie jetzt priorisieren?

Wenn wir die Grundlagen für ein priorisierbares Product Backlog in Form von sinnvoll geschnittenen Product Backlog Items geschaffen haben, können wir dieses nun auch priorisieren.

Nur wie? Viele Menschen priorisieren nicht gerne beziehungsweise neigen dazu, im Zweifel den Weg des geringsten Widerstandes zu gehen. Jeder, der sich schon einmal entscheiden musste, ob er/sie denn nun lieber den Frühjahrsputz macht oder doch lieber in den Biergarten/zum Badesee geht, weiß, wovon ich spreche.

Im Folgenden wollen wir uns über einige Methoden unterhalten, die uns den Umgang mit dem und das Priorisieren des Backlogs erleichtern. Welche Methode für das jeweilige Backlog die sinnvollste ist, hängt natürlich auch von der Art, Größe und Komplexität des Produktes ab, das über das Backlog abgebildet wird.

Aus dem Bauch heraus – Top 10 Features

So ungern wir auch priorisieren, so gerne bilden wir Rangfolgen und Top-x-Listen. Ob nun die Top 10 der Bewerbungstipps mit Zusagegarantie, die Top 100 der tollsten Songs aus den 80er Jahren oder die Top 20 der peinlichsten F-Promis, Rankinglisten erfreuen sich großer Beliebtheit.

So können wir auch unser zu entwickelndes Produkt nehmen und eine Top-x-Liste unserer PBIs erstellen. Dabei stellen wir uns bei jedem PBI die Frage, auf welchen Platz in der Rangfolge es kommt und warum. Jeder Platz in unserer Rangfolge darf natürlich auch nur ein einziges Mal belegt werden, soll also ein Feature einen bereits belegten Platz einnehmen, verdrängt es damit ein anderes nach oben oder unten.

Je weiter wir damit kommen und desto größer das Backlog, desto ungenauer kann dabei nach unten hin das Ranking werden. Schließlich bewerten und priorisieren wir unser Backlog ja regelmäßig neu.

Diese Methode eignet sich gut für den ersten Wurf einer Priorisierung und/oder wenig komplexe Produkte.

Prio by MVP/Kundennutzen

Einen Schritt weiter gehen wir, wenn wir unsere Priorität nicht nur aus dem Bauch heraussetzen, sondern konkret hinterfragen, welches unserer PBIs welchen Nutzen (Kundennutzen, ROI, Sichtbarkeit am Markt, …) generiert und warum. Wenn wir uns dann auf den größtmöglichen erzeugbaren Nutzen fokussieren, bekommen wir automatisch ein sinnvoll priorisiertes Backlog.

Wenn wir unsere Backlog Items wie weiter oben beschrieben so geschnitten haben, dass sie für sich alleinstehend wertschöpfend und auslieferbar sind, haben wir damit auch den ersten Schritt in Richtung iterativer Produktentwicklung und eines „Minimal Viable Product“ (MVP) getan. Hierbei entwickeln wir unser Produkt so, dass wir möglichst schnell eine erste verwendbare Version unseres Produktes haben. Mit dieser können wir unsere Annahmen, die wir beim Schneiden und Priorisieren unseres Backlogs getroffen haben, validieren und frühestmöglich nachbessern.

Ein hierfür gerne herangezogenes Bild stammt aus der Feder von Henrik Kniberg, einen sehr guten, dazu passenden Artikel gibt es auf seinem Blog.

Ein gutes Beispiel für diese inkrementelle Produktentwicklung ist der Messenger WhatsApp: Startete der Messaging Dienst im Jahr 2009 als reiner Instant Messenger ohne allzu viele Features, bietet er heute über Gruppenchats, Sprachnachrichten und VoIP-Telefonie eine Vielzahl von Funktionen, die zum ersten Release noch gefehlt haben.

WSJF

WSJF oder „Weighted Shortest Job First” ist eine Methode, mit der der erwartete Nutzen einer Funktion in Relation zum geschätzten, zur Umsetzung erforderlichen Aufwand gesetzt wird.

Eine simple Variante dies zu tun ist, analog zu den Methoden Estimation Poker oder Magic Estimation, mit denen ein Scrum Team die Komplexität der zu bearbeitenden Backlog Items schätzt, auch den „Wert“ dieser zu schätzen.

Dafür ordnen wir, genau wie bei der Komplexitätsschätzung, die Items relativ zueinander an, wobei ein höherer Wert in Story/Valuepoints einen entsprechend hohen oder niedrigen Wert in Relation zu den anderen Items bedeutet.

Genau wie beim Komplexitätsschätzen empfiehlt es sich auch hier, ein Referenzitem zu haben, anhand dessen die anderen Items eingeordnet werden können. Faktoren für diese Bewertung können zum Beispiel angenommener ROI, strategischer Nutzen und die Cost of Delay sein.

Aus dem angenommenen Nutzen und der Komplexität wird der Quotient gebildet (Nutzen/Komplexität). Aus dem Ergebnis können wir ableiten, welche Themen im Verhältnis zu ihren Kosten den höchsten Nutzen bringen und mit Zuhilfenahme dieses Wertes unser Backlog priorisieren. So stellen wir sicher, dass wir zuerst und fokussiert an den Themen arbeiten, die uns die größte „Gewinnmarge“ bieten => Weighted Shortest Job First.

Der Kreis schließt sich

Bei allem Priorisieren dürfen wir natürlich auch nicht vergessen, nach dem Liefern der gebauten Funktionalität zu validieren, ob die Annahmen, die wir für die Priorisierung getroffen haben, auch tatsächlich so eingetreten sind, wie wir uns das gedacht haben.

Diese Erkenntnisse können wir dann wiederum direkt in die (Re-)Priorisierung des verbleibenden Backlogs einfließen lassen.

Wenn Dir der Artikel gefallen hat, Du Unterstützung bei der Priorisierung Deines Backlogs brauchst oder einfach Deine Erfahrungen zu dem Thema mit uns austauschen möchtest, kontaktiere uns gerne über marketing@mid.de. Wir freuen uns auf Deine Nachricht!