Die Werkzeugkiste des Product Owners

Ich war mehr als vier Jahre Product Owner: zuerst für die TV-Produkte von Quickline, dann bei localsearch, dann als Head of Product Owners bei Lifestage, bevor ich die IT übernommen habe. Heute sitze ich auf der anderen Seite des Tisches. Ich arbeite mit Product Owners, ich stelle sie ein, und ab und zu muss ich erklären, warum ein Team mit vollem Backlog trotzdem nichts liefert, was zählt.

Selten fehlt dafür eine Methode. Meistens sind alle Methoden da, nur weiss niemand mehr, wofür. Die User-Story-Vorlage ist perfekt ausgefüllt, es gibt eine Definition of Ready, die niemand liest, und im Backlog liegen 600 Einträge, die niemand übers Herz bringt zu löschen.

Deshalb gehe ich in den nächsten Monaten die Werkzeugkiste durch, ein Werkzeug pro Text, in der Reihenfolge, in der man sie wirklich braucht: von der Produktvision bis zur Story, die das Team am Montag anfängt, und zur Checkliste, die sagt, dass sie fertig ist.

Die meisten dieser Werkzeuge sind nicht von mir. INVEST stammt von Bill Wake, Story Mapping von Jeff Patton, die Vorlage für die Vision von Geoffrey Moore. Ich nenne die Quelle jedes Mal. Von mir ist die Meinung dazu, welche Teile sich in der Praxis halten.

Ein Beispiel, von Anfang bis Ende

Werkzeuge, die man einzeln erklärt, stehen am Ende nebeneinander, statt zusammenzuhängen. Deshalb nutzt die ganze Serie ein einziges Beispiel.

Eine Firma mit 300 Mitarbeitenden verwaltet Ferienanträge in einer Excel-Datei auf einem Netzlaufwerk. Du schreibst deiner Teamleiterin eine E-Mail, sie antwortet, jemand leitet die Antwort an HR weiter, und HR trägt sie in die Datei ein. Niemand kennt sein Restguthaben, ohne nachzufragen. Jeden August ist das halbe Lager gleichzeitig weg.

Alle wissen, dass es schlecht ist, aber niemand ist dafür zuständig, es zu ändern. Wir bauen den Ersatz.

Das Beispiel ist bewusst langweilig. Die meiste Software, die eine Firma braucht, ist langweilig.

Wofür ein Product Owner da ist

Der Job passt in einen Satz: den Wert des Produkts maximieren. Alles andere dient dem.

Der Satz nützt nichts, solange sich das Team nicht einig ist, was «Wert» heisst. Beim Ferientool könnte es heissen, dass HR weniger Zeit damit verbringt, Bewilligungen nachzujagen. Oder dass im August keine Teams mehr halb leer sind. Oder dass Mitarbeitende ihr Guthaben kennen, ohne zu fragen. Diese Ziele ziehen in verschiedene Richtungen. Der Product Owner entscheidet sich, sagt laut, wofür, und bleibt länger als einen Sprint dabei. Genau dafür gibt es eine Roadmap: Sie macht aus Wert eine Verpflichtung statt einer Laune.

Sieben Grundsätze, die bleiben sollten

Wert maximieren. Wert bedeutet etwas für die Nutzer und für die Firma. Wenn du nur eines von beiden nennen kannst, hast du ihn noch nicht gefunden.

Laufend verfeinern. Eine Story hält fest, wer was will und warum. Ein gemeinsames Verständnis entsteht, wenn das Team sie zum richtigen Zeitpunkt aus mehreren Blickwinkeln anschaut (Fachseite, UX, Test, Entwicklung), nicht in einem grossen Workshop am Anfang.

Verschwendung reduzieren. Lösch Backlog-Einträge, die nicht den gewünschten Wert bringen, und zwar früh. Das gilt doppelt für Stories, die seit einem Jahr im Backlog liegen, ohne dass sie jemand angefasst hat. Vergiss die versunkenen Kosten: Die Zeit, die das Schreiben gekostet hat, ist so oder so weg.

Transparent sein. Stell Product Backlog, Produktziel, Sprintziel, Inkrement und Definition of Done dorthin, wo Team und Stakeholder sie sehen, und sprich darüber. Transparenz heisst auch zu erklären, warum sich Prioritäten geändert haben, und offen zu sagen, was nicht fertig wurde.

Es einfach halten. Wenn eine Story klein ist, kann sie für sich allein ein kleines Stück Wert liefern und in einen Sprint passen. Die Komplexität kommt früh genug von selbst, man muss sie nicht einladen.

Früh und günstig scheitern. Fehler passieren. Am günstigsten macht man sie, bevor etwas gebaut ist. Validier mit echten Nutzern, mach nur aus validierten Ideen Code und verwirf den Rest.

Qualität einbauen. In einem agilen Vorgehen ist Qualität keine Phase am Ende. Sie beginnt beim Backlog-Eintrag: regelmässige Refinements, eine Definition of Ready, testbare Akzeptanzkriterien und Pair Programming.

Fünf Dinge, die ein Product Owner wirklich tut

1. Kommunizieren. Der Product Owner ist die Schnittstelle zwischen Fachbereichen, Nutzern und Team. Der grösste Teil der Arbeit passiert in Refinements und Plannings und in all den Gesprächen dazwischen.
2. Die Nutzer kennen. Umfragen, Interviews, Prototypen, A/B-Tests, Feedbackkanäle. Wer die Nutzer nur über Stakeholder kennt, gibt die Meinung von jemand anderem weiter.
3. Bedürfnisse in Backlog-Einträge übersetzen. Dem Product Owner gehört das Was. Das Wie gehört dem Team.
4. Priorisieren. Den Backlog nach Business Value ordnen. Stories schreiben kann jeder, aber nur eine Person entscheidet über die Reihenfolge. Wenn das nicht klar ist, hast du keinen Product Owner, sondern ein Gremium.
5. Abnehmen und Feedback holen. Am Ende der Iteration prüft der Product Owner die Arbeit und nimmt sie ab. Danach holt er Feedback von denen, die sie nutzen, und macht daraus die nächsten Änderungen.

Wie das konkret aussieht, ist in jeder Organisation anders. Die fünf Aufgaben bleiben gleich.

Als Nächstes

Bevor wir die erste Anforderung ans Ferientool schreiben, ist eine Frage zu klären: wie viel man aufschreibt und wann. Die Antwort ist weniger, als du denkst, und später, als du denkst.