Übersicht und weiterführende Hinweise
Der Product Owner
Verschaffe dir eine Übersicht, was die Product Owner Rolle auszeichnet und nutze unsere Impulse, um wertstiftend Produkte zu entwickeln.
Der Product Owner
Was ist ein Product Owner?
Die Idee das eine dedizierte Person im Zusammenspiel mit agilen Teams hilft den Return on Invest zu maximieren stammt ursprünglich aus Scrum. Aufgrund des ansprechenden Namens, der immer größeren Verbreitung agilen Arbeitens und dadurch das Scrum nicht zu jedem Kontext passt, findet die Rolle aus außerhalb von Scrum immer weitere Verbreitung.
Der Scrum Guide definiert die Verantwortung des Product Owners als Teil des Scrum Guides, wie folgt:
Der Scrum Guide definiert die Verantwortung des Product Owners als Teil des Scrum Guides, wie folgt:
Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.
Der:die Product Owner:in ist auch für ein effektives Product‐Backlog‐Management
ergebnisverantwortlich, das Folgendes umfasst:
- das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren;
- die Product‐Backlog‐Einträge zu erstellen und klar zu kommunizieren;
- die Reihenfolge der Product‐Backlog‐Einträge festzulegen; und
- sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist.
Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die
Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in ergebnisverantwortlich.
Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre
Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar.
Der:die Product Owner:in ist eine Person, kein Gremium. Der:die Product Owner:in kann die Bedürfnisse vieler Stakeholder:innen im Product Backlog berücksichtigen. Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den:die Product Owner:in zu überzeugen.
In den folgenden Abschnitten dieser Seite arbeiten wir die verschiedenen Hintergründe und Implikationen zum Product Owner auf.
Bedeutung des Product Owners
Die Idee hinter der Rolle
Die Idee hinter der Rolle des Product Owner ist es übergreifende Klarheit über das „Produkt“ zu schaffen, dem, woran gearbeitet wird und diesem ein Gesicht zu geben bevor es noch existiert.
Dazu ist es entscheidend, dass es dem Product Owner gelingt alle Beteiligten auf ein gemeinsames und gemeinsam verstandenes Produkt-Ziel einzuschwören, meist ist dies ausgedrückt in einer Product Vision.
Diese Product Vision ist dann die Basis um ein Product Backlog aufzubauen, das in den kommenden Sprints für Klarheit sorgt, was nötig ist um die Product Vision umzusetzen und auch die Strategie abbildet wie das passieren soll. Genauso wie sich mit der Zeit der Kontext verändert in dem wir uns bewegen, verändert sich auch das Product Backlog und wir sprechen daher von einem „lebendigem Dokument“. Die Product Vision ist ebenfalls keine „Steintafel“ sondern änderbar, sie ist aber weniger volatil wie das Product Backlog und hilft dem Product Owner während der Entwicklung einen klaren Fokus halten zu können um spätere Abweichungen vom ursprünglichen Weg transparent darstellen zu können und um gegebenenfalls die Relevanz von Anpassungen fundiert diskutieren zu können.
Ein guter und umsichtiger Product Owner bindet in die Entwicklung des Product Backlogs nicht nur die externen Stakeholder, sondern vor allem auch die Entwickler ein um stets im Dialog zu bleiben und tatsächlich gemeinsam das Produkt zu entwickeln.
In einer idealen Scrum Umgebung gibt es neben dem Product Owner eigenverantwortlich agierende Entwickler die aus leichtgewichtigen Nutzeranforderungen einsetzbare Lösungen schaffen. Damit diese arbeiten können brauchen sie Informationen und Klarheit über bloße Anforderungen hinaus, besonders, wenn sie nicht nur Umsetzungen schaffen sollen sondern auch Vorschläge für alternative und bessere Wege zur Umsetzung.
Außerhalb des Scrum Teams gibt es meist eine große Anzahl an Stakeholdern die oft unterschiedliche Ziele verfolgen und andere Bedürfnisse an das Produkt haben. Die zweite große Aufgabe eines Product Owners, neben dem Orchestrieren von Anforderungen und Visionen an das Produkt, ist es, diese Beteiligten zusammen zu führen, sodass die Begegnung sinnvoll und effizient passiert.
Suchst du nach einem guten Einstieg in die Product Owner Rolle?
Erlebe Agilität und Scrum an 2-tägigen interaktiven Live-Online Training, um dein Verständnis der Rolle auf den nächsten Level zu heben.
Was sind die Eigenschaften eines guten Product Owners?
Die zentrale Verantwortung des Product Owners ist die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.
Damit ein Product Owner mit den Stakeholdern und Entwicklern das Produkt aus Nutzersicht gestalten kann, braucht er ein Verständnis für die Fachlichkeit, die Domäne für die das Produkt entwickelt wird. Ein Product Owner braucht kein Fachexperte sein, aber er:sie muss dialogfähig sein um mit technisch und fachlich kompetenten Entwicklern das Produkt gemeinsam zu besprechen.
Damit die Entwickler mit leichtgewichtigen Anforderungen arbeiten können, benötigen sie ein Vertrauensverhältnis zwischen PO und Entwicklern indem direkt Unklarheiten von den Entwicklern adressiert werden können.
Damit Fragen schnell adressiert werden können ist es wichtig, dass ein Product Owner verfügbar ist.
Damit ein Product Owner das Produkt effizient entlang eines Ziels entwickeln kann braucht es Konsequenz und Beharrlichkeit, die aber auch nur dann als Eigenschaften funktionieren, wenn ein PO mit einer ausreichende Autorität ausgestattet wird um Rückfragen selbstständig beantworten zu können und kurzfristige Anpassungen am Product Backlog vornehmen kann.
Ohne diese Autorität
- wird das Product Backlog zur Summe aller Kompromisse zwischen den beteiligten Stakeholdern und das Endprodukt wird wenig mit der Product Vision gemein haben.
- kann der PO nicht direkt und klar auf Rückfragen der Entwickler im Sprint reagieren, was zu Stillstand in der Entwicklung und Frustration bei den Entwicklern führt.
- ist es dem Product Owner nicht möglich ein gemeinsames Bild und eine Vision des Produkts aufrecht zu erhalten, weil er:sie gar nicht weiß wieso welche Änderungen passieren. Anstatt gemeinsam eine Produktentwicklung zielgerichtet voran zu treiben, wird er:sie zum Anforderungsschreiber für andere und das Einbinden der Entwickler und ihrer Ideen zu einer effizienteren Umsetzung gehen verloren.
Diese nötige Autorität braucht Unterstützung aus der Struktur des Unternehmens heraus, aber auch die persönliche Haltung eines PO, dem frühzeitigen Aufstellens gegenüber den Stakeholdern und einer proaktiven Klärung über den Ablauf der Entwicklung, damit geklärt ist welche Freiräume bestehen und wo gegebenenfalls nicht.
Ein Großteil einer effizienten und erfolgreichen Produktentwicklung besteht darin etwas nicht zu entwickeln das man entwickeln könnte, sondern sich darauf zu fokussieren das zu entwickeln, was man braucht um das Produktziel zu verwirklichen. Dazu benötigt es wiederum einen PO der das im Blick behält und den Stakeholdern das gegebenenfalls auch vermitteln kann. Diese Kernkompetenz eines PO ist wesentlich entscheidender als technische Fähigkeiten oder fachliches Wissen das über die Dialogfähigkeit hinausgeht.
Was sind die Aufgaben eines Product Owners?
Ein Product Owner ist für die „Maximierung des Return on Invests“ zuständig, doch was bedeutet das? Der Return on Invest, oder ROI ist eine Kennzahl die einerseits den „Return“ beinhaltet, andererseits den „Invest“. Beim „Return“ handelt es sich im Normalfall um das Softwareprodukt für das die Organisation Geld erhält. Der „Invest“ ist der Aufwand einer Organisation das Team samt Ausrüstung bereit zu stellen. Das dies besonders in einer Scrum-Umgebung möglichst stabil sein sollte, ist die Höhe des Invests für einen gegebenen Zeitraum einfach vorherzusehen. Für einen PO ist die Herausforderung abzuwägen was das Beste ist woran gerade jetzt gearbeitet werden kann, da beim Return sein Gestaltungsbereich liegt.
Die Umgebungen sind alle unterschiedlich und selbst im nachhinein ist es oft schwer festzustellen, ob man mit einer anderen Entscheidung nicht doch mehr Return erwirtschaften hätte können. – Hoffentlich glaubt man das zumindest, denn dann hat man etwas gelernt! Prinzipiell ist es für einen PO entscheidend zuerst einmal in die Situation zu kommen, dass zwischen einer getroffenen Entscheidung was entwickelt werden soll und dem „Return“ der Entscheidung möglichst wenig Zeit vergeht. Solange man etwas nicht ausrollt ist der Wert einer Entwicklung pure Spekulation. – Vergleichbar damit, dass ein Entwickler erst weiß ob eine Anforderung läuft, wenn sie auf dem Produktivsystem verwendet wird.
Der “Return on Invest” und der Product Owner
Wie nimmt ein Product Owner seine Aufgabe wahr und beeinflusst den „Return“? Sein zentrales Werkzeug dazu ist das Product Backlog. Durch dessen geschickte Priorisierung wird der Fokus auf die richtigen Dinge gelegt und so mit möglichst wenig Aufwand und zur richtigen Zeit möglichst viel Nutzen erzielt.
Das sogenannte Product‐Backlog‐Management ist die Hauptverantwortung eines PO, weil hier alles zusammen fließt aus dem das Produkt wächst und weiter wächst. Laut Scrum Guide umfasst das Product Backlog Management:
- das Produkt‐Ziel entwickeln und explizit zu kommunizieren;
- die Product‐Backlog‐Einträge erstellen und klar zu kommunizieren;
- die Reihenfolge der Product‐Backlog‐Einträge festzulegen; und
- sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist.
Ob ein Product Owner sich Unterstützung für die Erfüllung einer oder mehrerer dieser Aufgaben sucht oder die Umsetzung delegiert, ist bewußt für die Ausgestaltung in der jeweiligen Umgebung offen gelassen. Die Ergebnisverantwortung bleibt dabei aber immer unabhängig von der Delegation von Tätigkeiten beim Product Owner als Einzelperson.
Typische kontext-spezifische Herausforderungen
Als Product Owner ist es unsere Aufgabe, die Produktentwicklung effizient auszurichten. Das Ziel ist es mit den zur Verfügung stehenden Mitteln durch die Entwicklung der richtigen Funktionalitäten zum richtigen Zeitpunkt möglichst viel Wert zu liefern.
Blickt man auf die Arbeitsumgebung, ergeben sich von dort aus drei typische Problemfelder:
- Zu wenig Autorität innerhalb der Produktentwicklung
- Zu starke Abhängigkeit zu einzelnen Stakeholdern
- Innerhalb der Organisation ist keine dedizierte Product Owner Rolle vorgesehen
Im Folgenden möchten wir drei Kontexte herausgreifen und überzeichnen, in denen diese drei Probleme öfter vorkommen, damit diese potentiellen Probleme greifbarer werden, denen sich ein PO stellen muss. Diese drei Problemfelder können allerdings in jeder Organisation vorkommen oder sich auch mit der Zeit entwickeln.
Der Product Owner in einer klassisch hierarchischen Linien-Organisation
In einer klassischen Linien-Organisation ist das Hauptproblem eines PO, wie auch beim Rest des Scrum-Teams, starre Regeln die behindern aber nicht verändert werden können oder wenn, dann nur mit enormen Aufwand und speziell für den PO – eine „Pseudo-Autorität“. Das heißt, der PO ist für das Ergebnis „verantwortlich“, hat aber so gut wie keine oder nur sehr enge Entscheidungsfreiheit. Bei allen größeren Entscheidungen muß er Rücksprache mit Vorgesetzten halten.
Der PO ist natürlich nicht der Geldgeber des Projekts, wenn der Geldgeber aber nicht darauf vertraut, dass die mit der Ausgestaltung betraute Person die bestmögliche ist, sollte er sich eine andere suchen. Ohne dem Vertrauen verliert der PO seine Autorität und Entscheidungsflexibilität auf die ein Scrum Team angewiesen sind.
Findet man sich als PO in so einer Rolle wieder, ist innerhalb des Scrum Frameworks ein Tipp, sich auf eine gemeinsame Product Vision zu berufen und von allen Stakeholdern ein Commitment dazu abzuverlangen. So kann man eventuell grobe Abweichungen indem man die Personen die diese verlangen mit dem vormals vereinbarten Weg konfrontiert. Und man kann die Verantwortung für solche Abweichungen an die Entscheider transparent abgeben indem man zB vereinbart, wenn Abweichungen nötig oder verlangt werden die die bestehende Product Vision betreffen, dann müssen alle Stakeholder die bei ihrem Entstehen zugestimmt haben einverstanden sein.
Bestehen in der Organisation verschiedene Interessengruppen die in das Produkt eingebunden sind und gibt es keine entsprechende klare Verantwortlichkeit auf Seiten des PO, besteht das Risiko, dass die Rolle eines PO nur noch auf dem Papier existiert und die Vorteile die man durch diese Rolle hat nicht wirken können. Wichtig für den PO ist es, Verantwortlichkeiten klar darzustellen und transparentes Backlog – Management zu betreiben.
Der Product Owner in einer jungen hippen Start-Up Organisation
Im Kontext eines Start-Up ist selten mangelnde Entscheidungsbefugnis das Hauptthema, sondern das fehlen eines gemeinsamen Produkt-Verständnisses, bzw. dem “Hinterherlaufen” des oder dem potentiell wichtigsten Kunden, was eine gemeinsame und halbwegs stabile Produktvision die kommuniziert werden kann und die belastbar ist, sehr erschwert.
Hier kann ein Product Owner unterstützend wirken indem er versucht die Verantwortlichen zu einer solchen zu verpflichten und die Vorteile dieses Vorgehens für die Gesamtorganisation herausstellen und je nach Umfeld quasi als Scrummaster der Geschäftsführung oder der Produktentwicklung mitwirken. Vielleicht entwickelt sich daraus sogar die Rolle eines Scrum Masters für das Führungsteam. “Accountability” soll eine Stärke eines Product Owners sein, diese braucht aber eine Basis auf der sie aufbauen kann. Eine gemeinsame Idee für ein Produkt ist dafür eine Voraussetzung.
Ein junges Produkt einer jungen Firma ist wie eine zarte junge Pflanze und die Angst vor dem Rasenmäher ist groß. Daher begibt man sich oft in eine zu starke Abhängigkeit zu einzelnen Stakeholdern und verwirft grundsätzliche Ideen auf Tagesbasis zu Gunsten von spontanen Einfällen. Wichtig für den PO ist es die Integrität des Produkts zu wahren und alle Beteiligten auf eine Vision einzuschwören.
Der technische Product Owner
Manche Organisationen suchen nach einem “Technischen Product Owner” und verlangen von diesem hohe technische Anforderungen. Meist ist das Bedürfnis dahinter eine Person die gar nicht als Product Owner im agilen Sinne agieren soll, sondern eine Kommunikationsschnittstelle zwischen Team und Fachbereich ausfüllt. In der restlichen Zeit soll die Person dann oft auch im Team mit programmieren. Der Ruf nach einem Technischen Product Owner ist oft der Hilferuf einer Organisation weil erkannt wurde, dass es mit der gegenwärtigen Struktur nicht weiter geht. Es ist aber fraglich ob eine Person die für eine solche Rolle eingestellt wird die Verantwortung übertragen bekommt hier sinnvoll gestalten zu können. Wichtig ist, dass ein Product Owner nicht nur ein Durchreich-Posten von Anforderungen ist, sondern mit dem Team gemeinsam ein Produkt gestaltet und die Verantwortung erhält diese Aufgabe wahrnehmen zu können.
Ein PO ist organisationspolitisch immer in einer angespannten Situation. Deshalb empfiehlt es sich von Anfang an genau zu hinterfragen wofür man verantwortlich ist und welche Verantwortungen man wie wahrnehmen kann. In der Rolle dann ist es wichtig transparent herauszustellen was notwendig ist oder wäre und was man vielleicht mangelnder Befugnis halber nicht selbst machen kann, aber was gemacht werden muss, inklusive einer Übersicht über Probleme und sich daraus ergebender Schäden und Verzögerungen.
Was kann ein PO gegen kontextspezifische Probleme tun?
Die drei vorher genannten Probleme ergeben sich aufgrund der Organisationsstruktur. Man könnte jetzt sagen “Das ist halt so, damit muss man leben”, weil ein PO darauf ja keinen Einfluss hat. Damit kann man aber oft nicht leben und es ist nicht korrekt, dass nur jemand “von oben” etwas ändern kann. Ein entscheidender Beitrag ist transparent zu machen, dass ein Problem vorliegt und dann auch zu zeigen was das Problem verursacht. – Am besten zusammen mit einem Lösungsvorschlag. Dann kann einem “von oben” eventuell geholfen werden.
Ein anderer Ansatz ist durch transparentes Handeln auf Unstimmigkeiten aufmerksam zu machen. Wenn ein PO beispielsweise keine Priorisierungen vornehmen darf oder sich immer wieder Organisations-Teilbereiche im Backlog “vordrängen”, dann hilft es transparent zu zeigen welche Themen sich zu Gunsten welch anderer vorgedrängt haben und wie dies in Relation steht zu den gesteckten Zielen und Meilensteinen.
Diese drei Bereiche kann man als erfahrener Product Owner oft schon beim Einstellungsgespräch abklopfen. Es empfiehlt sich von Anfang an sich bewusst zu machen, dass man mit Schwierigkeiten rechnen muss und gezielt zu schauen welche das sein werden um von Beginn an eine klare Position beziehen zu können. Aber selbst wenn es von Beginn an wenige solcher Probleme gibt, so können sich diese später entwickeln. Das Universal-Allzweck-Mittel (das selten die Probleme löst, aber immer etwas hilft) ist Transparenz und eine gute “Product Ownership”.
Der Weg zu einer guten “Product Ownership” – Die großen Herausforderungen, der Weg zum Erfolg
Wir haben weiter oben kontextuelle Problem-Szenarien besprochen (Linien-Organisation / Start-Up / Technische Rolle und PO) bei denen ein erfahrener Product Owner zwar ein wenig entgegensteuern kann um das Problem abzumildern, letztlich ist es aber notwendig, dass die Organisation sich dahin entwickelt, dass ein Product Owner ihre Rolle ausleben und damit das Produkt optimal entwickeln kann. Denn auch nur dann kann das gesamte Scrum Team seine Stärke ausspielen. Diese Problembereiche liegen nur bedingt im Verantwortungsbereich eines Product Owners, es ist aber ihre Verantwortung sich um die Herausforderungen zu kümmern.
Wenn die Voraussetzungen für ein effizientes Arbeiten gegeben sind, welche Herausforderungen bleiben dann noch übrig, wo die Verantwortung für die Lösung überwiegend beim Product Owner liegt? Das Schlagwort heißt “Product Ownership” – die Produktverantwortung wahrzunehmen. Hierzu zählen die Kernaufgaben der Rolle, angefangen vom Backlog Management über die Arbeit mit dem Entwicklerteam und der Kommunikation mit den Stakeholdern.
Product Backlog Management
Das Backlog Management ist das Hauptmittel zur Erfüllung der Hauptaufgabe, dem Optimieren des Return On Invest für meinen Product Owner.
Das Product Backlog ist eine Liste von Anforderungen die zur Erfüllung der Product Vision führen, idealerweise transparent jederzeit von jedem Teammitglied und Stakeholder einsehbar, mit einer eindeutigen Priorisierung und einer der Priorisierung entsprechenden Granularität.
Anforderungen die mit der Erfüllung der Product Vision nichts zu tun haben, müssen dringend hinterfragt werden. Entweder ist die Product Vision nicht vollständig, was kein Problem ist, dann sollte sie entsprechend angepasst werden, sodass alle am Projekt beteiligten Bescheid wissen, oder die Anforderung bringt das Produkt nicht weiter in die Richtung in die gegangen werden soll.
Ein nicht transparentes Backlog oder ein nicht übersichtliches verhindert ein Gespräch über die notwendigen Schritte zu führen und schließt Beteiligte von dem Prozess aus darüber nachzudenken wie es eventuell schneller und mit weniger Aufwand möglich wäre zum Produktziel zu gelangen. Außerdem begünstigt ein intransparentes Backlog die Erfüllung von „Nebeninteressen“ und Machtkonflikten innerhalb einer Organisation, die letztlich zu Lasten des Produkterfolges ausgetragen werden.
Nur eine eindeutig priorisierte Liste bietet dem Team die Möglichkeit sich auf Anforderungen vorzubereiten und dem Product Owner diese zur richtigen Zeit auszuarbeiten. Wenn jemand anders als der PO eine Priorisierung vornehmen darf stellt das einen großen Konflikt zu Lasten der effizienten Produktentwicklung dar. – Was gleichzeitig aber auch nicht bedeutet, dass niemand Einfluss nehmen darf oder soll, letztlich ist es wichtig, dass die Stakeholder dem PO erklären wieso eine Anforderung eine entsprechende Wichtigkeit hat. Die ultimative Entscheidung wann sie an der Reihe der Umsetzung bestimmt aber nicht nur ihre Wichtigkeit sonder auch der Aufwand, technische und eventuell fachliche Voraussetzungen, Risikoabwägungen, etc. Deshalb ist es vorgesehen und entscheidend, dass die ultimative Priorisierung in der Hand des PO bleibt.
Entsprechend Ihrer Priorisierung sollte eine Anforderung im Product Backlog eine Granularität aufweisen. Ein PO kann nach ein paar Sprints in etwa abschätzen wie viele Anforderungen das Entwicklerteam umsetzen kann und sollte danach trachten stets Anforderungen für 1,5 bis 2 Sprint soweit „fertig“ zu haben, dass er sie dem Entwicklerteam in einem Sprintplanning für das Sprintbacklog anbieten kann. Mehr als das ist eine Verschwendung, weniger ein Risiko. Mehr als ca. 30 Anforderungen im Backlog zu haben verursacht erfahrungsgemäß mehr Probleme als Nutzen. Deshalb ist ein ständiges Überarbeiten und Anpassen des Backlogs erforderlich. Das empfohlene Format dieser Anforderungen ist in Scrum die User Story, weil dieses Format viele Vorteile bietet und von vornherein gut mit der Scrummethodik harmoniert. So zeichnet sich eine User Story beispielsweise dadurch aus, dass die schriftliche User Story lediglich eine Erinnerung an ein oder mehrere Gespräche darstellt, die zwischen dem PO und dem Entwicklerteam stattgefunden haben.
Anforderungen die so unklar und schwammig sind, dass es schwer fällt sie zu priorisieren, sollten nicht im Produkt Backlog landen, weil es sich nicht um „Anforderungen“ handelt, sondern um Ideen. Um von einer Idee zu einer Anforderung zu kommen braucht es ein Minmimum an Klarheit und ein Indiz dafür, dass diese vorhanden ist, ist, dass diese Idee relativ zu anderen Anforderungen in ihrer Wichtigkeit priorisierbar ist. Es spricht nichts gegen ein unpriorisiertes Ideenpool aus dem ein Product Owner immer wieder Material für neue Anforderungen schöpft.
Das Backlogmanagement dient also nicht nur als Sammlung von Anforderungen für das Entwicklerteam, es zeigt auch allen Stakeholdern wie weit die Entwicklung ist und welche Schritte als nächstes für am sinnvollsten erachtet werden um das Produktziel zu erreichen. Dem PO dient es auch als Mittel der Kommunikation, innen und außen und zur Vorhersage über Features.
In der konkreten Umsetzung des „Wie“ gibt es so viele Lösungen wie Product Owner. Selbst wenn zwei Product Owner dasselbe Tool verwenden um „ihren“ Backlog zu organisieren, so werden sie es anders machen. Von mehr oder minder komplexen analogen Lösungen mit Karteikarten und Post-Its über Jira oder anderen technischen Hilfsmitteln kann man alles finden. Wichtig ist, dass die gewählte Lösung dabei unterstützt das Backlog Management effizient zu gestalten und eine transparente Übersicht für alle zu bieten.
Wie agiert der Product Owner im Scrum Flow?
Orientiert am Scrum Flow wollen wir euch in diesem Abschnitt aufzeigen, wie der Product Owner typischerweise in den einzelnen Events mit den unterschiedlichen Protagonisten interagiert.
Der Product Owner im Sprint Planning
Für das Sprint Planning stellt der Product Owner eine ausreichende Vorbereitung sicher, damit im Sprint fokussiert Wert in Richtung eines gemeinsamen Sprint-Ziel geschaffen werden kann.
Dazu muss im Sprint Planning:
- Aus der Orientierung des Produktes ausgerichtet auf das gemeinsame Produkt-Ziel ein sinnvolles Sprint-Ziel definiert werden.
- Darauf ausgerichtet ein Sprint Backlog mit passenden Items ausgerichtet auf dieses Ziel zusammengestellt werden.
- Das Sprint Backlog ausreichend vorbereitet sein, dass die Entwickler sich gut fühlen mit dem gesetzen Sprint-Ziel und jeder weiß wo er anfangen kann daran mitzuwirken.
Schließlich übernehmen die Entwickler die Verantwortung für die Arbeit in richtung des angestrebten Sprint-Ziels.
In Vorbereitung auf das Planning
In Vorbereitung auf dieses Event liegt die Verantwortung zur Vorbereitung die Pflege des Product Backlogs beim Product Owner. Er sorgt dafür, dass dieses sowohl einen guten Ausblick zum Produkt Ziel gibt (wichtig zur gemeinsamen Definition eines Sprint-Ziels) und genügend Optionen gut für den Sprint vorbereitet sind (wichtig um Backlog Items passend in Richtung zum Sprint-Ziel zu kombinieren und überraschend unzureichend vorbereiteten Items in der Sprint Planung vorzubeugen).
In der Planung selbst
Einerseits versuchen wir für die Entwicklung eines konsistenten Produktes mit möglichst hohem Wert eine Orientierung zu geben, andererseit wollen wir gemeinsam mit dem Scrum Team das Produkt und den Sprint dazu ausgestalten.
Oft ist dieses gemeinsame Ausgestalten des Sprints kollaborativ im Scrum Team die größte Herausforderung.
Deswegen hat es sich bewährt, dass der Scrum Master als unabhängiger Facilitator durch dieses Event führt.
So kann sich der Product Owner einbringen und auch das Scrum Team in der Ausrichtung des Sprint herausfordern ohne gefahr zu laufen, dass Scrum Team zu unrealistischen Commitments zu drängen oder in manier eines Micro-Managers auszusteuern.
Achtung: Eine gute Vorbereitung des Sprint Plannings ist wichtig. Sie sollte die Grundlage sein, damit wir fokussiert und gemeinsam den Sprint planen können.
-> Mehr dazu beim Backlog Refinement.
Der Product Owner im Sprint
Da die Entwickler die Verantwortung für die Ausrichtung des Sprints auf das Sprint-Ziel übernommen haben, kommt dem Product Owner hier eine eher passive Rolle zu.
Würde der Product Owner sich Verantwortlich fühlen die Arbeit im Sprint zu überwachen, dann würden seine Aufgaben proaktiv das Backlog in Richtung des übergreifenden Sprint Ziels zu optimieren und die proaktive Arbeit mit den Stakeholdern leiden. Diese Dysfunktion führt oft zu einem schlecht vorbereitetem Sprint, wodurch der Product Owner sich dann berufen fühlt die Entwickler im Sprint wieder aktiver zu den unzureichenden Themen selbst auszusteuern. In diesem dysfunktionalen Teufelkreislauf befinden sich in der Praxis leider zu viele Scrum Teams.
Achtung: Falls du als Product Owner das dringende bedürfnis hast jedes Detail in der Arbeit im Sprint zu nachvollziehen zu wollen oder sogar aktiv einsteuern möchtest, dann ist das Zusammenspiel mit den Entwicklern unzureichend geklärt. In diesem Fall wäre es gut dies in der Sprint Retrospektive ´oder im Sprint Planning anzusprechen.
Der Product Owner im Sprint Review
Das Sprint Review wird oft als Abnahme-Meeting ausgestaltet. Dabei geht es in diesem Termin um das Inspezieren des Inkrements und aus den daraus entstehenden Learnings das Product Backlog anzupassen.
Idealerweise sollte aus der proaktiven Einbindung des Product Owners durch Entwickler bereits vor dem Sprint Review klar sein, was fertig ist und was nicht. Dadurch kann der Fokus des Sprint Reviews deutlich mehr auf dem Austausch über die Ergebnisse liegen und dem Ableiten von Implikationen in Richtung des Sprint Ziels.
Gute Product Owner haben über Backlog Refinement und Sprint Planning ein so gutes Verständnis über den Ausblick vom Produkt geschaffen, so dass die Einordnung direkt von den Entwicklern erfolgen kann und diese sich auch aktiver in den inhaltlichen Austausch mit den Stakholdern begeben können. Dies ist für mich der belastbarste Indikator für ein Scrum Team in dem sich jeder inhaltlich zum Ziel einbringen kann und wir in enger Zusammenarbeit tolle Lösungen in Richtung eines gemeinsamen Produkt-Ziels entwickeln können.
Achtung: Solltest du als Product Owner das dringende Bedürfnis haben, dass nur du die Einführung in das Sprint Review geben kannst, dann ist dies ein klarer Indikator für ein unzureichendes Verständnis vom Produktkontext bei den Entwicklern.
Der Product Owner im Sprint Retrospektive
Da Anfang der Product Owner nicht als fester Teil der Retrospektive definiert war, gibt es noch heute den irrglauben, dass der PO nicht Teil der Retrospektive ist. Dabei ist der Product Owner ein wichtiges Mitglied der Scrum Teams. Oft ergeben sich aus der Reflexion der Arbeit inklusive des Zusammenspiels mit dem Product Owner wichtige Optimierungspotenziale.
Achtung: Viele Product Owner versuchen sich in der Sprint Retrospektive mit falscher Zurückhaltung. Dabei ist es wichtig, dass sie ihre Perspektive und Bedürfnisse genauso offen in die Retro bringen, wie jedes andere Mitglied des Scrum Teams.
Der Product Owner beim Product Backlog Refinement
Technisch gesehen ist das Product Backlog Refinement kein Scrum Event, da sie eben nicht zwingend zu einem festen Zeitpunkt ritualisiert und wiederkehrend stattfinden muss.
Nach meinem Verständnis geht das Ansetzen eines Refinements vom Product Owner aus, da er zwar verantwortlich ist für das Product Backlog Management und doch gut daran tut sich Unterstützung aus dem Scrum Team zu suchen. Ausgehend von dem Bedürfnis Feedback und Hilfe bei der Ausgestaltung des Backlogs und den zeitlichen Präferenzen der Entwickler gestaltet man dann gemeinsam das Refinement inhaltlich und zeitlich aus. Der kollaborative Gedanke und die gegenseitige Unterstützung sollte hier im Vordergrund stehen.
Idealerweise liegt der Schwerpunkt nicht nur auf den nächsten Items für den kommenden Sprint, sondern beinhaltet auch Feedback zu großen Backlog Items in einer frühen Phase.
Achtung: Ein typischer Fehler ist es das Product Backlog Refinement auf die Einbindung weniger seniorer Entwickler zu reduzieren, denn dann fehlt das Feedback in der Breite aus dem Scrum Team. Dies führt oft zu unnötigen späten Missverständnissen und zu einem disengagement bei den nicht involvierten Scrum Team Mitgliedern. Deswegen rate ich hier eher Herangehensweisen zu entwickeln mit denen alle Entwickler sehr kurz und fokussiert eingebunden werden.
