Product Owner – Scrum Rolle im Detail
Product Owner (kurz PO) ist eine von drei Rollen im Scrum Framework. In diesem Beitrag beschreiben wir im Detail, was es bedeutet, PO zu sein. Wir sprechen über die wichtigsten Aufgaben eines POs und die Eigenschaften und Fähigkeiten, die er braucht, um diese erfolgreich zu meistern. Wir geben dabei Beispiele für typische Herausforderungen in dieser Tätigkeit und typische Dysfunktionen einer Organisation, die rund um diese Rolle entstehen können.
Dieser Artikel umfasst mehr als 4000 Wörter und es kann sinnvoll sein, ihn in mehreren Durchgängen zu lesen. Für eine leichtere Orientierung ist hier das Inhaltsverzeichnis:
- Warum braucht es einen Product Owner?
- Product Backlog
- Eigenschaften
- Hauptaufgaben und -Beziehungen
- Fähigkeiten
- Richtigen PO finden
- Abschluss
Zielsetzung
Das Hauptziel eines Product Owners kann man sehr kurz zusammenfassen: Es besteht darin den Wert der Arbeit der Entwicklungsteams zu maximieren. Dazu hat nur er/sie die Macht zu bestimmen, woran entwickelt wird. Diese Entscheidungsbefugnis von höchster Tragweite (und nicht bestimmte Fähigkeiten) ist das, was diese Rolle auszeichnet. Dadurch können in einer gegebenen Organisation nur Wenige diese Rolle tatsächlich einnehmen.
Warum braucht es einen Product Owner?
Product Owner vs. Stakeholder
Es gibt viele Personen und Organisationen, die ein legitimes Interesse an den Ergebnissen der Entwicklungsarbeit haben. Wir nennen sie alle Stakeholder. Dazu gehören Kunden, Nutzer, Führungspersonen, Manager, Partnerunternehmen und viele Weitere. Die Stakeholder haben grundsätzlich unterschiedliche Macht zu bestimmen, was mit dem Produkt passieren soll. Sie haben aber alle auch eigene Ziele und sind nicht nur dem Produkt verpflichtet. Der Product Owner ist die einzige Person, die nur dem Erfolg des Produkts verpflichtet ist und auch die einzige Person mit der Autorität zu entscheiden, was entwickelt wird.
Das folgende Video führt sehr anschaulich vor, was passiert wenn es keinen echten PO gibt. Vielleicht kennen sie solche Situationen aus ihrer Arbeitspraxis. Wir haben ähnliche Entwicklungen schon häufig beobachtet.
Produktivitätsgewinn durch den Product Owner
Grundsätzlich bietet Scrum einer Organisation eine Reihe von Produktivitätsgewinnen (hier im Einzelnen erklärt). Damit einige davon tatsächlich eintreten, muss die PO-Rolle tatsächlich mit der dafür nötigen Macht ausgestattet sein. Hier in Kürze:
- Die meisten Ideen in einer Organisation sind schlecht. Dazu gibt es viele Statistiken, z.B. scheitern 7-8 von 10 StartUps im Portfolio eines typischen Investors. Dabei werden diese StartUps vor dem Investment einer höheren Due Diligence unterzogen, als alle uns bekannten Ideen innerhalb eines Unternehmens.
- Es braucht die Macht und des Abstands eines Product Owners, um jede Idee immer erst als Experiment zu betrachten und die meisten abzulehnen.
- Zur Quantifizierung: Im besten Fall dem Pareto-Prinzip (80/20) folgend schafft man ein Fünffaches an Ergebnis durch Konzentration auf die wichtigen 20% des Aufwands.
- Wenn der PO große Entscheidungen selbst trifft, dann erfolgen Entscheidungen viel schneller, als wenn erst ein Gremium oder weitere Höhergestellte diese treffen müssen. Geschwindigkeit von Entscheidungen ist eine sehr wichtige Variable von der Projekterfolg abhängt.
- Die Motivation der Teams, die mit dem echten PO zusammenarbeiten, ist sehr hoch. Sie wissen, ihre Vorschläge haben Bedeutung und können den Pfad den ihr Produkt nimmt unmittelbar verändern. Teams die dagegen mit Menschen arbeiten, die keine eigene Entscheidungsbefugnis haben, fühlen sich oft ohnmächtig und unbedeutend.
Product Owner (PO) Zertifizierung
Wenn Sie mehr Interesse haben, heißen wir sie gern in unseren Product Owner Trainings willkommen.
Das Product Backlog – Wichtigstes Werkzeug
Das Product Backlog ist das Hauptwerkzeug eines POs. Es ist eine geordnete Liste von allen Arbeitspaketen (Einträgen), die für die Zukunft geplant sind. Es repräsentiert den aktuellen Plan für die zukünftige Arbeit des Entwicklungsteams. Welche Reihenfolge (und damit Priorität) die Einträge im Product Backlog haben, bestimmt letztendlich nur der Product Owner.
Für die Anpassungsfähigkeit (oder Agilität) einer Organisation ist es von entscheidender Bedeutung, dass die Prioritäten dieser Transparent sind. Das Werkzeug dafür ist Product Backlog.
Damit das Product Backlog seine Funktion erfüllen kann, arbeitet das Entwicklungsteam nur an den Arbeitspaketen aus dem Product Backlog und nimmt keine direkten Aufträge anderer Stakeholder an. Alle Stakeholder sind jederzeit dazu aufgerufen ihre Ideen, Wünsche, Kommentare etc. zu äußern, und damit das Product Backlog zu beeinflussen. Das Product Backlog ist jederzeit für alle Stakeholder sichtbar und verständlich.
Eigenschaften
Autorität
Die wichtigste Eigenschaft eines Product Owners ist die alleinige Autorität über das “Was” für das Entwicklungsteam zu entscheiden. Dabei ist ein guter PO keinesfalls ein Despot, der auf niemanden hört und nur seinen eigenen Vorstellungen folgt. Das wäre tatsächlich ein schneller Weg in den Ruin. Ein guter PO folgt in der Regel den Vorschlägen seiner Kollegen, aber wenn es drauf ankommt, wissen alle, dass nur er entscheiden kann. Häufig ist ein guter Product Owner ein hochrangiger Entscheider in einem Unternehmen, zum Beispiel der Chef der Produktentwicklung oder der CEO.
Typische Herausforderung – Vorgesetzte mitnehmen:
In den meisten Fällen hat ein Product Owner außer Kunden und Nutzern auch Vorgesetzte Personen innerhalb des Unternehmens, zum Beispiel den Geschäftsführer. Und auch wenn ein CEO die Rolle des POs übernimmt, hat er häufig Investoren, an die er regelmäßig berichtet. Es gibt also immer Menschen, die einem theoretisch sagen könnten, was man tun soll.
Alleinige Autorität bedeutet, dass ein Product Owner nicht den Vorschlägen seiner Vorgesetzten folgen muss, insbesondere wenn es um die Ordnung der Einträge im Product Backlog geht. Um diese Autorität zu erhalten, braucht es viel Vertrauen am Anfang und eine kontinuierliche Pflege dieses Vertrauens während der Arbeit. Wie passend, dass wir in Scrum iterativ arbeiten und deshalb regelmäßig Ergebnisse zeigen und bei Bedarf unseren Fokus verändern können.
Typische Dysfunktion – keine Autorität:
Eine der häufigsten Dysfunktionen, die wir in Unternehmen antreffen ist ein Product Owner ohne Autorität. Dann muss er bei allen ansatzweise wichtigen Entscheidungen ein Gremium zusammenrufen oder seine Entscheidungen immer wieder ändern, weil andere Personen tatsächlich entscheiden. Die Folgen kann man im Video oben sehen. Zusätzlich ist es ein sehr unangenehmer Zustand für die betreffende Person und die Entwickler.
Unternehmerische Herangehensweise
Ein großartiger Product Owner denkt und handelt wie ein Entrepreneur. Die aktuelle Forschung beschreibt diese Herangehensweise mit dem Wort: Effectuation. Es handelt sich um eine andere Logik mit der Entscheidungen getroffen werden. Sie geht von der Annahme aus, dass die Zukunft nicht vorhersagbar ist und konzentriert sich auf das Mögliche im Jetzt und auf das Ausnutzen der sich bietenden Möglichkeiten.
In jedem Fall ist ein guter PO eine wirtschaftlich affine und ökonomisch denkende Person. Er hat eine Affinität zur Domäne der Kunden, Nutzer und ggf. anderer Stakeholder.
Typische Dysfunktion – “technischer” Product Owner
Wir sehen häufig, dass Unternehmen die Funktion eines “technischen” POs einführen. Tatsächlich braucht ein Product Owner nur so “technisch” zu sein, wie seine Nutzer oder Kunden es sind. Technische Entscheidungen bzgl. der Implementierung werden in Scrum von Produkt-Entwicklern getroffen.
Typische Ursachen für den Bedarfs der Unternehmen nach einem „technischen PO“ ist, dass es interne Entwicklungsteams gibt, die selbst keine sichtbare Funktionalität liefern können und jemanden brauchen, der deren Aufgaben managt. Die Einführung der Funktion „technischer PO“ verschlimmert und institutionalisiert das Problem in der Regel, statt es zu beheben.
Eine Person als Product Owner je Produkt
Hier zunächst ein Zitat aus dem Scrum Guide:
“The Product Owner is the sole person responsible for managing the Product Backlog.”
Warum ist es wichtig, dass der PO genau eine Person ist? Gegenfrage: Wer ist autorisiert die endgültige Entscheidung über die Reihenfolge zu treffen, wenn es zwei oder mehr POs gibt?
Und was passiert bei vielen Entwicklungsteams für ein Product? Wieder Scrum Guide:
“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.”
Selbst dann, gibt es nur einen Product Owner. Er kann Aufgaben an eine oder mehrere andere Personen delegieren. Er kann sich sehr viel helfen lassen. Strukturell ist aber klar, dass er die einzige Person mit der endgültigen Entscheidungsautorität über die Reihenfolge der Einträge im Product Backlog ist.
Haupt-Aufgaben und -Beziehungen
Wir stellen hier kurz die 5 Beziehungen eines POs vor und die sich daraus ergebenden Aufgaben bzw. Fähigkeiten, die ein Product beherrschen sollte. Danach stellen die einzelnen Fähigkeiten im Detail vor.
Beziehung 1: Product Owner zu Entwicklungsteam(s)
Die Entwicklungsteam(s) helfen dem PO, das bestmögliche Produkt für den Kunden zu erstellen. Sie müssen sehr konkret verstehen, was sie als nächstes erstellen sollen und ob das, was sie bereits gebaut haben, sein Ziel erreicht hat. Der PO muss wiederum wissen, was die Teams brauchen und wie er ihnen helfen kann.
In dieser (und der folgenden) Beziehung ist der Fokus des PO für ein gemeinsames Verständnis des Ziels der Produktentwicklung zu sorgen. Die Erstellung der Produkt-Vision und ihre Vermittlung sind wichtige Hauptaufgaben des POs. Er muss die Vision immer wieder verständlich und empathisch seinen Kollegen vermitteln und auch die anstehenden kleineren Aufgaben in den Kontext der großen Vision stellen. Hier hilft es sehr ein guter Storyteller zu sein. Eine andere wichtige Fähigkeit in dieser Beziehung ist es die anstehenden Arbeitspakete so vermitteln, dass sie keine Lösung vorgeben. Dazu ist es notwendig sein eigenes Denken und Kommunizieren in die Problem- und Lösungs-Domäne zu unterscheiden.
Beziehung 2: Product Owner zu Stakeholder
Der Product Owner und die Entwicklungsteam(s) arbeiten darauf hin das bestmögliche Produkt für die Stakeholder zu erstellen. Die Stakeholder wollen wissen, welche Priorität die Funktionen haben, die ihnen wichtig sind, und häufig auch die Gründe für die gewählte Priorisiereung. Ein guter PO bezieht sie so weit wie möglich ein. Er versucht die Ziele und Bedürfnisse seiner Stakeholder zu erfahren und andere Informationen zu sammeln, die ihm helfen, Prioritäten zu setzen.
Hier kommt die schon oben erwähnte Fähigkeit, in der Problem-Domäne denken zu können, zum Tragen. Statt einfach die vom Kunden gewünschte Lösung in sein Product-Backlog aufzunehmen, sollte man immer nur die Herausforderung des Kunden in die Entwicklung hineingeben. Lösungen werden von den Entwicklern vorgeschlagen, diese brauchen dafür das tiefere Kundenverständnis, welches sie unter anderem mit Hilfe des Product Owners entwicklern. (siehe nächsten Abschnitt).
Um viele verschiedene Stakeholder einzubeziehen braucht ein Product Owner häufig auch die Fähigkeit mit großen Gruppen souverän umzugehen, d.h. Gruppen-Prozesse zu facilitieren. Dabei hilft ihm auch der Scrum Master oder Agile Coach.
Um die Reihenfolge der Einträge im Product Backlog festzulegen, dessen Transparenz und Verständlichkeit sicherzustellen, bedient sich ein PO verschiedener Werkzeuge und Modelle, auf die wir im Fähigkeiten Kapitel eingehen.
Beziehung 3: Stakeholder zu Entwicklungsteam(s)
Die Teams arbeiten darauf hin, das bestmögliche Produkt für die Stakeholder zu schaffen. Sie müssen den Kontext für Features kennen und detailliertes Wissen in der Kunden-Domäne haben. Im Idealfall entwickeln Teams ihre Lösungen in Zusammenarbeit mit Stakeholdern. Dabei lernen sie die wesentlichen und nicht nur die oberflächlichen Ziele und Probleme der Kunden kennen.
Das kontinuierliche Funktionieren dieser Beziehung ist eine der wichtigsten Aufgaben eines POs. Dazu verbindet er regelmäßig Stakeholder mit den Entwicklern und fungiert nicht als Ersatzkunde oder Vertreter der Kunden. Es ist die Pflicht des Product Owners sicherzustellen, dass die Entwickler ihre anstehende Arbeit verstehen. Aber er macht es in der Regel nicht indem er alles selbst erklärt, sondern indem er die notwendigen Stakeholder mit dem Team direkt verbindet.
Das führt nebenbei auch zu einem hohen Maß an Identifikation der Entwickler mit ihrem Produkt, was große Auswirkungen auf die Produktqualität und die Motivation hat. Das ist im übrigen genau das, was mit dem Scrum-Wert Commitment gemeint ist.
Typische Dysfunktion – PO hat als einziger Kontakt zu Nutzern oder Kunden
In einigen Unternehmen, die wir heute antreffen, kennen die Entwickler nicht die Nutzer und sehen nicht, wie die Nutzer mit ihrem Produkt interagieren. Das führt über sehr kurze Zeit dazu, dass sie nicht bei Produktentscheidungen mitdenken und mitreden können. Und wenn sie jeden Tag in der Entwicklung kleine Produktentscheidungen treffen, liegen sie häufig falsch, was zu Mehrarbeit führt. Die Motivation erlischt sehr schnell. Das einzige Mittel dagegen ist die Verbindung des Teams mit Nutzern und dafür ist der Product Owner verantwortlich. Dazu arbeitet er auch mit dem höheren Management zusammen (siehe nächsten Abschnitt).
In diesem Video sehen ein Beispiel, wie es aussieht, wenn das Team sehr kundennah arbeitet:
Product Owner (PO) Zertifizierung
Wenn Sie mehr Interesse haben, heißen wir sie gern in unseren Product Owner Trainings willkommen.
Beziehung 4: Product Owner zu höherem Management
Höheres Management außerhalb der Produktgruppe (Portfoliomanager, C-Level-Führungskräfte usw.) sollte den Product Owner als den endgültig Verantwortlichen für den Produkterfolg betrachten. Er ist dafür verantwortlich, den langfristigen Entwicklungsfortschritt sichtbar zu machen und das (möglicherweise implizite) Mandat des höheren Managements zu realisieren, um die gewünschten Auswirkungen (z. B. ROI oder Steigerung des Marktanteils) zu erreichen.
Höheres Management ist in der Regel auch der Personenkreis, der die Autorität besitzt das Organisationsdesign zu verändern. Der PO arbeitet mit dem höheren Management und dem Scrum Master zusammen, um das Organisationsdesign kontinuierlich zu verbessern. Um das obige Beispiel aufzugreifen, kann er mit ihnen an der Intensivierung des Kundenkontakts der Entwicklungsteams arbeiten.
Beziehung 5: Product Owner zu Scrum Master
Die obigen Beziehungen entstehen unmittelbar aus der Verantwortung des POs für die Arbeit am Produkt, aber diese Beziehung ist anders. Hier geht es darum wie sich die Fähigkeiten und das Verhalten des Product Owners mit der Zeit ändern. Es bezieht sich nicht auf das konkrete WAS der Product Owner macht, sondern das WIE. Ein Scrum Master ist ein Coach für den PO und kennt seine Sorgen, Fragen und Herausforderungen. In schwierigen Momenten kann er ein wohlwollender Zuhörer sein. Scrum Masters beobachten und geben Feedback, dadurch unterstützen sie den PO in fachlicher und menschlicher Hinsicht in seinem Wachstum. Außerdem hilft ein Scrum Master dem PO in Fragen rund um Facilitation von Gruppen von Stakeholdern oder bei der Arbeit mit Entwicklern.
Welche Fähigkeiten hat ein Product Owner?
Produkt-Vision vermitteln
Eine Vision kann in der Regel nur schwer durch irgendein Dokument vermittelt werden. Man ist dann von einer Vision ergriffen, wenn man sie mitfühlen kann.
Wenn man sich hineinversetzt hat in eine Situation und ein konkretes Bedürfnis spürt. Wenn man dann verstanden hat, dass man heute keine adäquate Lösung finden kann und vielleicht eine Frustration oder Traurigkeit darüber fühlt. Wenn man dann den möglichen neuen Weg oder das neue Werkzeug vorgestellt bekommt, und am eigenen Leib die kleine Freude der neuen Realität verspürt. Diese neue Welt ist heute noch nicht da, aber mit der gemeinsamen Arbeit, ist es möglich sie zu erreichen.
Die Vision bildet einen der wichtigsten Rahmen für die Arbeit der Entwicklungsorganisation. Sie hilft Entwicklern in kleinen und mittleren Implementierung-Fragen, die mehrmals täglich auftreten, gute Entscheidungen zu treffen. Sie hilft allen sich in Diskussionen auf das Wichtigste zu fokussieren. Die abgestimmte Vision hilft einem PO in Gesprächen mit Stakeholdern, um die Richtung beizubehalten.
Die Geschichte der Vision erzählt ein Product Owner immer wieder. Und dabei wird sie immer facettenreicher. Er passt sie an die Zuhörer an. Je nach Kontext brauchen sie mehr oder weniger Informationen, um sich in die Situation eines Kunden/Nutzers hineinversetzen zu können. Man nennt diese Erzähl-Fähigkeit auch Story-Telling und sie lässt sich gut einzeln erlernen.
Häufig geht es nicht darum, die ganze Vision zu erzählen, sondern darum den Kontext zu den kleineren aktuellen Aspekten der Arbeit herzustellen. Zum Beispiel: Wenn sich das Scrum-Team am Anfang eines Sprints auf ein Sprint-Ziel einigen will, ist es sehr hilfreich zu überprüfen, inwiefern dieses auf die Vision einzahlt.
Die Problem- und Lösungs-Domäne unterscheiden
Beispiel:
Stellen Sie sich vor sie gehen zu einem Designer / Künstler und bestellen bei ihm eine Hochzeitskarte für ihre Hochzeit:
Variante A: Dabei beschreiben sie genau, wo was abgebildet sein soll und in welcher Farbe, mit welchen Farben bzw. Computerprogrammen gemalt wird und wie auf was gedruckt werden soll.
Variante B: Sie beschreiben, was das Bild auf der Karte vermitteln soll, welche Stimmung erzeugt werden soll und wie hochwertig die Wahrnehmung der Karte sein soll.
Im Fall A befinden sie sich voll in der Lösungs-Domäne. Einem Experten ist dadurch ggf. nicht klar, was sie eigentlich mit der Hochzeitskarte erreichen wollen. Wenn er den Auftrag übernimmt, macht er ihn stumm und nach Anleitung und wenn etwas schief läuft, ist es ihre Verantwortung.
Im Fall B befinden wir uns in der Problem-Domäne. Durch ihre Aussagen erzeugen sie den Wunsch des Experten zu Fragen mehr zu Verstehen und Ihnen kreative Vorschläge zu machen. Er fühlt sich respektiert und wertgeschätzt und macht möglicherweise exzellente Vorschläge auf die Sie selbst nie gekommen wären.
Ein Product Owner bringt in der Regel nur die Probleme zu seinen Entwicklungsteams und Menschen, die ihnen dabei helfen können mögliche Detailfragen zu klären. Auf diese Weise stellt er nicht nur die Motivation sicher, sondern ermöglicht sich selbst und dem ganzen Team viel effektiver zu Arbeiten. Warum?
Für unsere Arbeit gilt in der Regel das Pareto-Prinzip. Mit 20% des Aufwands sind 80% der gewünschten Ergebnisse erzielbar. In dem die Lösungsfindung den Experten überlassen wird, werden für die meisten Herausforderungen verschiedene Implementierungswege vorgeschlagen, mit verschiedenen Vor- und Nachteilen. Durch das Auswählen dieser ist es häufig möglich mit einem Bruchteil des Aufwands die gewünschten Ergebnisse zu erreichen.
Es ist sehr wichtig in der Problem-Ebene strukturiert im Detail denken und formulieren zu können. Hier helfen unter anderem die folgenden Werkzeuge, auf die wir in unseren Product Owner Schulungen (offen / in-house) näher eingehen:
- Jobs to Be Done
- Outcome Based Innovation
- Impact Mapping
- Facilitation von Gruppenprozessen
Bei allen Herausforderungen in Gruppenprozessen kann sich der Product Owner von seinem Scrum Master Unterstützung wünschen. Das ist insbesondere in der frühen Phase der Zusammenarbeit empfehlenswert.
Verständnis der Product Backlog Einträge sicherstellen
Wie schon oben beschrieben, verbindet ein Product Owner die Entwickler direkt mit Nutzern und anderen Stakeholdern, damit diese die Anforderungen so detailliert verstehen können, wie sie es für die Entwicklung brauchen. Wie stellt man aber sicher, dass diese Unterhaltungen effektiv, verbindend und lebendig ablaufen? Das ist typischerweise eine Facilitations-Herausforderung. Unser Lieblingsformat für diese Art von Interaktion ist Specification by Example.
Durch dieses Format erarbeiten die Entwickler selbst die Spezifikationen, aus von Nutzern stammenden Beispielen des gewünschten Verhaltens des Endprodukts. Nach einer Phase in der die Stakeholder Beispiele vorstellen und Fragen der Entwickler beantworten, kann anhand eines offenen Beispiels überprüft werden, ob die Entwickler das Wunschverhalten so verstanden haben, wie es gemeint war.
Durch die Facilitation können viele konstruktive Unterhaltungen gleichzeitig laufen und alle sind aktiv involviert, sodass niemand abschaltet. Am Ende haben sich alle Anwesenden mit den zukünftigen Product Backlog Einträgen beschäftigt und es gibt ein breites Verständnis.
Umgang mit Stakeholder-Input
Eine andere Herausforderung für Facilitation besteht darin, die Wünsche und Ideen vieler verschiedener Stakeholder transparent zu machen, miteinander in Diskussion zu bringen, um eine bessere Grundlage für Richtungsentscheidungen zu haben.
Hier gibt es einige Facilitations-Strukturen unter anderem aus dem Bereich Innovation Games. Diese wollen wir hier kurz auflisten, um ihnen die Recherche zu vereinfachen, ohne hier im Detail auf die Strukturen einzugehen:
- Prune the product tree
- Hot Tub
- Product Box
- Buy a feature
- Business Value Poker
Langfristigen Entwicklungsfortschritt transparent machen
In Scrum verzichten wir auf kleinschrittige Vorhersagen zu Lieferzeitpunkten. Das würde dazu führen, dass wir versuchen würden detaillierte Lieferpläne zu erstellen und wir wissen, dass es in unserer Umgebung verschwendete Zeit wäre. Wir sind aber durch die empirische Prozesskontrolle dennoch in der Lage mit Deadlines umzugehen, wie sie zum Beispiel bei einer geplanten Produktvorstellung auf einer Messe gegeben wären. Dazu helfen uns Burn-Down-Charts , die anzeigen wie viel Arbeit einer bestimmten Kategorie noch im Product Backlog ist.
Angenommen wir wollen bei der Messe die neuen Features unseres Produkts zum Thema X vorstellen. Wenn wir mit der Bearbeitung des Themas X starten, markieren und schätzen wir alle Einträge zum Thema X. Angenommen wir haben 4 Monate bis zur Messe und 2-wöchige Iterationen. Dann können wir am Ende jeder Iteration eintragen, wie viel Arbeit ist noch da zum Thema X. Dabei wird automatisch mitberücksichtigt, wenn neue Einträge dazu kommen/entfernt werden oder sich die Schätzungen verändern etc.
So könnte ein Burndown dann am Ende des 3. Sprints aussehen:
In diesem Fall wäre die Deadline nach Sprint 8 erreicht. Das heißt nach dem 3. Sprint wissen wir, wir werden scheinbar nicht alles schaffen, wenn es so weitergeht wie bisher. Ein Product Owner aktualisiert einen solchen Chart regelmäßig am Ende des Sprints und schafft so nachhaltig Vertrauen. Sieht ein Chart so aus wie der obige, wissen alle Beteiligten früh, dass sie reagieren müssen. Man kann versuchen einfachere Lösungen zu finden, einige Wünsche wegzustreichen etc. Und nach 6 Sprints sieht es im besten Fall schon ganz anders aus.
Durch diese kontinuierliche Transparenz des Entwicklungsfortschritts schafft es ein Product Owner langfristig und nachhaltig das Vertrauen des höheren Managements oder der Investoren sicherzustellen, die ihm dauerhaft die Autorität verleiht, die er für seine Arbeit braucht. Diese Transparenz kann schmerzhaft sein, wie im obigen Beispiel nach 3 Sprints. Aber so werden auf eine ganz natürliche Weise immer wieder wichtige Unterhaltungen ausgelöst und Probleme nicht verschleppt.
Priorisierung des Product Backlogs
Es gibt viele Denkmodelle, die ein Product Owner heranziehen kann, um die Reihenfolge der Einträge im Product Backlog festzulegen. Scrum schreibt das in keiner Weise vor. Es kann auch sein, dass in bestimmten Situationen der PO über geheime Informationen verfügt, auf deren seine Entscheidung basiert. In der Regel sollte aber die Priorisierung für die Umwelt (Entwickler und Stakeholder) nachvollziehbar und verständlich sein.
Entscheidungen über die Reihenfolge von kleinen Einträgen
Bei vielen (in unserer Erfahrung bei den meisten) Priorisierungsentscheidungen lässt sich ein PO von den Vorschlägen seiner Entwicklungsteams leiten. Schließlich sind es die Entwickler, die eine große Anforderung im Refinement in kleinere Einträge zerteilen und so am besten wissen welche Schritte Sinn machen könnten. Gleichzeitig ergeben sich durch das Refinement und die Zerteilung verschiedene Möglichkeiten dafür, wie umfangreich ein Thema umgesetzt wird. Meist konzentriert sich die Arbeit eines POs darauf die Vor- und Nachteile der jeweiligen Umsetzungsoption zu verstehen und sich für eine zu entscheiden.
Ein Beispiel: Angenommen wir betreiben einen Online-Shop und wollen nun eine größere Anforderungen implementieren: Zahlung mit verschiedenen Kreditkarten.
Das Entwicklungsteam könnte es in folgende Unterpunkte herunterbrechen:
- Erfolgreiche Zahlung bei Eingabe gültiger Visa-Kreditkartendaten, Adresse Deutschland
- Fehler bei Eingabe gültiger Visa-Kreditkartendaten, Adresse nicht in Deutschland
- Fehler bei ungültiger Kreditkartennummer (Visa) nach Prüfung beim Provider
- Fehler bei ungültiger Kreditkartennummer (Visa) ohne Provideraufruf
- Fehler bei ungültiger Karte (Visa)
- Fehler bei Überschreitung des Limits (Visa)
- Alle (anderen) Fehler bei Zahlung mit Visa nach Prüfung beim Provider
- Zahlung mit anderen Kreditkarten (Mastercard, AMEX, Diners Club..)
Ein PO könnte jetzt zum Beispiel sagen, dass er gern die Einträge wie vorgeschlagen umsetzen möchte aber vor der Fehlerbehandlung in 2-6, ersteinmal die 7 umsetzen würde. Das Entwicklungsteam könnte antworten, dass aus technischen und legalen Gründen der Eintrag 2 notwendig ist, um Zahlungen auch in der einfachsten Form zu ermöglichen. Man würde sich also auf die Reihenfolge 1,2,7,8 einigen und die anderen Einträge ersteinmal weiter unten im Product Backlog einordnen.
Entscheidungen über die Reihenfolge größerer Themen
Wenn wir beim obigen Beispiel bleiben: Wie entscheidet ein PO, ob er zuerst Visa oder Mastercard Zahlungen implementieren sollte? Oder sollte vielleicht eher das aktuelle Aussehen der Zahlungsoberfläche vereinfacht werden, damit nicht so viele Nutzer den Zahlungsprozess abbrechen? Oder macht es mehr Sinn einen Newsletter einzuführen, statt die Zahlungen zu verbessern? Oder ist es wichtiger auf die aktuelle Änderung in der Datenschutzgesetzgebung zu reagieren, weil es dort das Risiko gibt abgemahnt zu werden?
Jedes einzelne dieser Themen ist in der Regel größer (eher Wochen/Monate Arbeit für ein Entwicklungsteam) und hat einen eigenen prinzipiell berechenbaren Einfluss auf das wirtschaftliche Ergebnis. Sie steigern entweder den Umsatz, verringern die Kosten, reduzieren Risiken oder bauen die Grundlagen für zukünftige Einnahmen. Um die Reihenfolge für die Bearbeitung dieser Themen festzulegen gibt, es das Konzept der “Cost of Delay” oder Kosten der Verzögerung. Es ist aus unserer Sicht eines der flexibelsten Konzepte für die Priorisierung. Hier stellen wir das Konzept nur kurz vor, wenn sie mehr Interesse haben, heißen wir sie gern in unseren Product Owner Trainings (offen / in-house) willkommen.
Zunächst muss man verstehen, dass die Entscheidung für bestimmte Einträge immer bedeutet, dass die anderen Einträge jetzt nicht umgesetzt werden. Das heißt, sie werden verzögert geliefert. Deshalb ist es die natürlichste Frage, die man sich stellen kann:
Was kostet es uns, die Bearbeitung eines Themas um 1 Monat zurückzustellen?
Diese Betrachtungsweise hilft uns alle Product Backlog Einträge mit verschiedenen Nutzungsszenarien auf einer Skala zu bewerten und damit vergleichbar zu machen. Wenn weniger Menschen ihre Zahlung abbrechen, was wird uns das je Monat bringen? Wenn Menschen sich zum Newsletter anmelden, was erhoffen wir uns davon?
Es ist klar, dass alle unsere Antworten auf diese Fragen letztendlich Spekulationen sein werden. Wir müssen z.B. annehmen, wie viele Nutzer heute abspringen, weil sie nicht die Möglichkeit haben mit einer Kreditkarte zu zahlen. Oder wie viele unserer Newsletter-Abonnenten zu zahlenden Kunden werden könnten. Dafür gibt es manchmal Vergleichswerte von Wettbewerbern oder aus anderen Quellen. Aber am Ende kann niemand den zukünftigen Nutzen mit hoher Präzision vorhersagen. Das brauchen wir aber auch nicht:
Erstens: Selbst mit ungenauen Werten finden wir in der Regel heraus, dass sich die Wertigkeit verschiedener Themen im Backlog voneinander um Größenordnungen (Faktor 10) unterscheidet. Dann wird die Entscheidung leicht.
Zweitens hilft uns die Frage und der Versuch den Wert eines Eintrags zu quantifizieren dabei, eine gemeinsame klare Formulierung unserer Hypothesen zu erreichen. So können wir, nach dem etwas implementiert wurde und wir wissen ob es funktioniert oder nicht, viel konkreter untersuchen, welche unserer Annahmen zutraf und welche nicht. Auf diese Weise lernen wir nachhaltig etwas über unsere Kunden und ihre Interaktionen mit unserem Produkt.
Wie findet man den richtigen Product Owner?
In diesem Teil sprechen wir von POs in echter Produktentwicklung. Aber auch wenn Sie Scrum in anderen Kontexten einsetzten, hilft es ihnen möglicherweise diese Unterscheidungen zu verstehen. Wir unterscheiden drei Fälle des Organisations-Designs:
Produktentwicklung – Das Unternehmen entwickelt intern ein Produkt und vermarktet es an Kunden außerhalb. Beispiele für Produkte wären iPhone, Facebook, Xing etc. Hier wäre der beste Product Owner eine Person aus dem Unternehmen, die entweder ein erfahrener Produktmanager mit entsprechender Position oder der hierarchische Leiter der Einheit für die Produktentwicklung ist. Es ist wichtig zu beachten, dass die Person einen Business-Hintergrund und -Funktion hat.
Interne Produktentwicklung – Hier geht es um die Entwicklung von Produkten deren Nutzer Mitarbeiter der gleichen Firma sind. Beispiele wären: Makler bei Investmentbanken, die ihre Software zum Handeln nutzen oder Software für Vertriebsmitarbeiter einer Firma, die viel reisen. Ein guter Product Owner für die interne Produktentwicklung ist in der Regel innerhalb der Nutzergruppe, die das System verwenden wird, und ist eng involviert und tief erfahren in der wirklichen Arbeit, die das System leisten wird.
Projektentwicklung – Hier entwickelt ein Unternehmen im Auftrag einzelner Kunden die gesamte Software. Typische Beispiele sind digitale Agenturen, die für ihre Kunden Apps oder große Webseiten entwickeln. Der entscheidende Punkt hier liegt darin, dass ein Product Owner im besten Fall aus dem Kunden-Unternehmen stammt und wie bei der internen Entwicklung in die praktische Arbeit involviert ist und direkte Verbindung zu den Nutzern hat.
Die folgende Abbildung zeigt den PO in verschiedenen Organisationen:
Abschluss
In diesem Beitrag haben wir die wichtigsten Eigenschaften, Aufgaben und Fähigkeiten eines aus unserer Sicht großartigen POs beschrieben. Ähnlich wie in unserem Beitrag zur Scrum Master Rolle, ist das Hauptziel dieses Artikels die Rolle möglichst verständlich und anfassbar darzustellen. Ein guter Product Owner kann mit einem Bruchteil der hier dargestellten Fähigkeiten sehr viel Mehrwert für sein Unternehmen erschaffen. Insbesondere kann er mit Hilfe seines Scrum Master alles notwendige bei der Arbeit erlernen. Die einzige unabdingbare Voraussetzung ist, dass er die Autorität innehat und damit das explizite Vertrauen seiner Stakeholder geniesst.
Wenn Ihnen dieser Artikel weitergeholfen hat, würden wir uns über eine Erwähnung in den sozialen Medien oder Blogs sehr freuen. Und hier finden sie einen detaillierten Beitrag über den Scrum Master.
Verwendete Bilder stammen entweder von uns selbst (alle abgelichteten Personen haben ihr Einverständnis erteilt) oder sind zur Nutzung freigegebene Bilder von less.works.
Dieser Wissensbeitrag wurde von Anton Skornyakov geschrieben und zuletzt am 23.12.2020 aktualisiert.