Die Quellen
Wir wollen nutzerzentriert und datenbasiert arbeiten, also entstehen viele Aufgaben aus UX-Research und aus der Auswertung von Daten. Nicht weniger wichtig sind die Eingaben des Entwicklungsteams: Designer und Programmierer weisen auf notwendige Maßnahmen hin um Design Debt und Technical Dept zu verringern oder im Idealfall ganz zu vermeiden. Eine dritte Kategorie von Aufgaben sind von betriebswirtschaftlicher Art, denn digitale Produkte müssen Mehrwert für das Geschäftsmodell haben. Dies können auch Anforderungen sein, die keinen Mehrwert für den Nutzer bedeuten und sogar von Nachteil für das Entwicklungsteam sein können.
Die Priorisierung
Da die Menge der zu erledigenden Arbeit immer größer ist als die Menge der Ressourcen, die zur Abarbeitung zur Verfügung stehen, müssen Aufgaben priorisiert werden. Um diese Priorisierung durchzuführen brauche ich in meiner Rolle als Produktmanager die Mitarbeit des Teams und der Stakeholder. Aus diesen Quellen erhalte ich die Informationen, die Grundlage jeder Priorisierung sind.
Wichtige Parameter sind:
- Die logische Abfolge von Entwicklungsschritten: Auch wenn der Mensch, der das Geld verwaltet, dringend nach einem jetzt unbedingt dringenden Feature fragt, kann dieses nicht bearbeitet werden, wenn es an notwendigen Voraussetzungen fehlt.
- Mehrwert ausliefern: Untern den verschiedenen Priorisierungsmethoden präferiere ich für die meisten Fällen die Vier-Sektoren Matrix, in der ich Aufgaben nach Mehrwert und Aufwand einsortiere und auf diese Weise den Weg zu schnellem Mehrwert aufgezeigt bekomme.
- Das „Big Picture“ im Auge behalten: Als Produktmanager sitze ich am Schnittpunkt zwischen allen Beteiligten. Jeder Quelle für Aufgaben wird ihr Anliegen mit der höchsten Wichtigkeit herein reichen. Meine Aufgabe ist es, das „große Ganze“ im Auge zu behalten und die Aufgaben so zu priorisieren, dass der meiste Mehrwert für den Erfolg des Produktes erzeugt wird.
Die Erledigung
Aus den beiden oben genannten Schritten fällt eine priorisierte Liste von Aufgaben heraus. Dies ist das Backlog. Es gibt unterschiedliche Arten von Backlogs und unterschiedliche Methoden, diese zu organisieren.
Im Folgenden nenne ich einige Grundsätze, die mir die tägliche Arbeit leichter machen:
- Trennung von Idee und Verpflichtung: Ich richte mindestens zwei Backlogs ein. Eines für alle Aufgaben, die mit aus den verschiedenen Quellen hereingereicht werden. Das ist die Ideenliste. Das zweite Backlog wird mit Aufgaben gefüllt, zu deren Erledigung sich das Team verpflichtet hat. Das ist das Development Backlog. Die meisten Aufgaben des Ideenbacklogs werden niemals erledigt. Nur Aufgaben, die validiert wurden und in einem Zustand sind, der abgearbeitet werden kann („definition of ready“), wechseln von der Idee zur Verpflichtung.
- Aus der Priorisierung leiten sich nur drei Kategorien ab: Now (Aufgaben, die jetzt erledigt werden), Next (Aufgaben, die als nächstes erledigt werden) und Later (Aufgaben, die irgendwann erledigt werden). Eine vierte Kategorie ist Done, dort finden sich Aufgaben, die erledigt wurden und deshalb auch keine Aufgaben i.e.S. mehr sind.
- Das Backlog als Werkzeug: Der Begriff „Pflege“ erscheint mir unzureichend, um die Arbeit mit dem Backlog zu beschreiben. Das Backlog ist eines meiner wichtigsten Werkzeuge bei der täglichen Arbeit. Es dient nicht nur als Grundlage für die Planung aller Entwicklungsschritte. Es ist auch unverzichtbar für die Kommunikation mit allen Beteiligten und es macht Entscheidungen sichtbar. Und natürlich muss es auch gepflegt werden.