Agile Softwareentwicklung: Die vielen Hüte der Product Owner
<html> <header class=„article-header“><h1 class=„articleheading“>Agile Softwareentwicklung: Die vielen Hüte der Product Owner</h1><div class=„publish-info“> Cornelia Seraphin</div></header><figure class=„aufmacherbild“><img src=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/shutterstock_1234118449-d66452ac27e08525.jpeg“ srcset=„https://heise.cloudimg.io/width/700/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/shutterstock_1234118449-d66452ac27e08525.jpeg 700w, https://heise.cloudimg.io/width/1050/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/shutterstock_1234118449-d66452ac27e08525.jpeg 1050w, https://heise.cloudimg.io/width/1500/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/shutterstock_1234118449-d66452ac27e08525.jpeg 1500w, https://heise.cloudimg.io/width/2300/q75.png-lossy-75.webp-lossy-75.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/shutterstock_1234118449-d66452ac27e08525.jpeg 2300w“ alt=„“ class=„img-responsive“ referrerpolicy=„no-referrer“ /><figcaption class=„akwa-caption“>(Bild: iChzigo/Shutterstock.com)</figcaption></figure><p><strong>Product Owner müssen je nach Kontext verschiedene Aufgaben übernehmen. Die sechs Kernrollen lassen sich als Hüte darstellen – eine Vorstellung.</strong></p><p>Product Owner ist mehr als nur eine Rolle in Scrum. Je nach Kontext müssen sie verschiedene Aufgaben aus unterschiedlichen Bereichen übernehmen. Als Hüte dargestellt ergeben sich sechs konkrete Aufgabengebiete für Product Owner. Der Artikel stellt sie vor und gibt Tipps für den Umgang damit.</p><p>Der <a href=„https://scrumguides.org/“ rel=„external noopener“ target=„_blank“><strong>Scrum Guide [1]</strong></a> liefert auf seinen rund 13 Seiten nur wenige Aussagen zu den Tätigkeiten eines Product Owners (die Seitenzahl variiert je nach Sprache). Um das volle Potenzial dieser in Scrum essenziellen Rolle zu entfalten, sollten deshalb alle Beteiligten die Aufgaben und Verantwortlichkeiten von Product Ownern kennen und auf geeignete Weise in ihre jeweilige Projekt- und Organisationsstruktur integrieren. Um dabei nicht den Überblick über die vielfältigen Aufgaben zu verlieren, hilft es, sich die Product Owner mit unterschiedlichen Hüten vorzustellen.</p><h3 class=„subheading“ id=„nav_hut_des0“>Hut des Produktmanagers</h3><p>Als Produktmanager übernehmen Product Owner die inhaltliche und wirtschaftliche Verantwortung für das Produkt. Sie sind Visionäre und Wertsteigerer, gleichzeitig müssen sie den Erfolg des Produkts sicherstellen.</p><figure class=„a-u-inline-left a-inline-image a-u-inline“><div></div></figure><p>Inhaltliche Verantwortung bedeutet: Sie sorgen dafür, dass das passende Produkt für ihre Kunden entwickelt wird. Um das zu bewerkstelligen, müssen sich Product Owner sehr gut in ihrer Domäne und im Markt auskennen und sollten die aktuellen Trends und ihre Mitbewerber kennen. Die Analyse des Marktes und der Kundenzufriedenheit ist eine durchgängige Tätigkeit während der gesamten Produktentwicklung.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Product Owner: Definition aus dem Scrum Guide</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent-container“ data-collapse-target=„“><p>„The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.“</p><p>– Scrum Guide, November 2020</p></div><p>Product Owner entwickeln und kommunizieren das Produktziel. Damit es in den für den jeweiligen Kontext richtigen Schritten umgesetzt wird, erstellen Product Owner eine Roadmap für die Produktentwicklung. Davon leiten sie Release-Pläne bis hin zu den Sprint-Zielen ab – jedes Release soll schließlich einen Mehrwert für die Kunden schaffen. Je kürzer die Release-Zyklen ausfallen, desto schneller erhalten Product Owner die Rückmeldung der Kunden darüber, ob das Scrum-Team bei der Produktentwicklung den richtigen Weg eingeschlagen hat.</p><p>Gleichzeitig müssen Product Owner bei ihrer Release-Planung beachten, wie aufwendig es für ihre Kunden ist, ein neues Release einzusetzen. Sollte es nicht den erhofften Kundennutzen liefern, oder falls sich die Bedürfnisse beziehungsweise die Rahmenbedingungen ändern, passen Product Owner ihre ursprüngliche Planung kurzfristig an, prüfen wiederum diesen neu eingeschlagenen Weg und geben so den optimalen Fahrplan für die Produktentwicklung vor. Schritt für Schritt entsteht also genau das Produkt, das die Kunden wirklich wollen und brauchen.</p><p>Product Owner sind obendrein für das Marketing ihres Produkts verantwortlich. Sie verbreiten ihr Produktziel im Unternehmen und bringen zudem die Produktentwicklung mit den Unternehmenszielen in Einklang.</p><h5 id=„nav_wirtschaftliche1“>Wirtschaftliche Verantwortung für das Produkt</h5><p>Mit ihrer wirtschaftlichen Verantwortung für das Produkt müssen sie dafür Sorge tragen, dass sich die Investition der Produktentwicklung für ihr Unternehmen lohnt. Sie nutzen geeignete Kennzahlen zum Monitoring, um den Return on Investment (ROI) im Auge zu behalten und den Nutzen für Kunden und Unternehmen sicherzustellen.</p><p>Es ist wichtig, dass Product Owner das Motto „Inspect and Adapt“ leben (Überprüfen und Anpassen); und zwar vom Produktziel über das Messen und Verfolgen des gelieferten Wertes mit jedem Release bis hin zur wiederholten Validierung des Produkts mit den Stakeholdern und dem Marktplatz.</p><h5 id=„nav_sich_bei_den2“>Sich bei den Aufgaben helfen lassen</h5><p>Product Owner dürfen sich bei ihren vielfältigen Aufgaben helfen lassen und müssen notwendige Analysetätigkeiten des Marktes und der Wettbewerber nicht selbst erledigen. Sie können diese Arbeit an Mitarbeiter des Unternehmens delegieren, etwa an die Marketingabteilung, an andere Teammitglieder oder auch an externe Partner. Sie müssen allerdings die Daten und aktuellen Trends kennen, um die bestmöglichen Entscheidungen treffen zu können. Außerdem sorgen sie dafür, dass sie ihr Wissen darüber an das Scrum-Team weitergeben.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Strategische Aktivitäten des Produktmanagements</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent-container“ data-collapse-target=„“><p>Viele der Aktivitäten des Produktmanagements sind nicht direkt mit Scrum verknüpft. Dennoch müssen Product Owner diese Aktivitäten kennen und in ihrer Arbeit als Produktmanager und „Value Maximizer“ berücksichtigen.</p><p><strong>Strategische Aktivitäten für das Produktmanagement</strong>:</p><ul class=„boxtitel“><li>Industrie und Wettbewerber analysieren</li><li>Return on Investment maximieren</li><li>Machbarkeitsprognose erstellen</li><li>Produktstrategie entwickeln</li><li>Releases planen</li></ul><ul class=„boxtitel“><li>Kunden und ihre Bedürfnisse identifizieren</li><li>Fahrplan für die Produktentwicklung erstellen</li><li>Ergebnisse überwachen</li><li>Externe Kommunikation erstellen</li></ul><ul class=„boxtitel“><li>Produkt weiterentwickeln</li><li>Releases einführen</li><li>Business Case erstellen</li><li>Produktanforderungen identifizieren</li><li>Markteinführung des Produkts</li></ul><ul class=„boxtitel“><li>Strategie zur Kundenbindung entwickeln</li><li>Funktionalitäten für das Produkt definieren</li><li>Produktlebenszyklus managen</li><li>Produkt einstellen</li><li>Marketing und Branding</li></ul></div><h3 class=„subheading“ id=„nav_hut_des3“>Hut des Requirements Engineers</h3><p>Als Requirements Engineer stellen Product Owner sicher, dass das Produkt die Anforderungen und Erwartungen aller Stakeholder befriedigt. Sie verantworten, dass die Anforderungen im Product Backlog beschrieben, verstanden sowie sortiert sind und dass das Backlog für jeden Stakeholder zugänglich ist.</p><figure class=„a-u-inline-left a-inline-image a-u-inline“><div></div></figure><p>Ein gutes Produkt lässt sich nur entwickeln, wenn Product Owner die Wünsche und Bedürfnisse der Kunden und aller anderen Stakeholder kennen. Diese Stakeholder gilt es entsprechend zu identifizieren und während der gesamten Produktentwicklung aktiv zu betreuen. Mittels Methoden des Requirements Engineering ermitteln, klären und priorisieren sie die sich ergebenden Anforderungen sämtlicher Stakeholder an das Produkt. Das bedeutet auch, dass sie mit zuweilen widersprüchlichen Anforderungen und Bedürfnissen konfrontiert sind. Zu den Sprint Reviews laden sie die geeigneten Stakeholder ein, um Feedback einzuholen und die weitere Produktentwicklung in eine angemessene Richtung zu steuern.</p><p>Die konkreten Anforderungen – detaillierte ebenso wie grobe Ideen und lose Hypothesen – erfassen Product Owner im Product Backlog. Das Backlog sortieren sie anhand des Business Values, des Risikos sowie anhand der Abhängigkeiten zwischen den Product Backlog Items (PBI). Auch die Schätzgröße und somit die Kosten für die Umsetzung einer Anforderung fließt in die Sortierung mit ein. Product Owner verantworten auch, dass die PBIs in angemessener Detailtiefe beschrieben sind und die Developer die Items verstehen. So stellen Product Owner sicher, dass Developer die Items im bevorstehenden Sprint auch tatsächlich umsetzen können.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Definition of Done</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent-container“ data-collapse-target=„“><p>Die Definition of Done ist ein Artefakt aus dem Scrum Guide. Product Owner und die Developer erstellen sie gemeinsam. Sie enthält alle Qualitätskriterien, die ein Product Backlog Item (PBI) erfüllen muss, um als fertig umgesetzt zu gelten und in das aktuelle Produktinkrement integriert werden zu können.</p><p>Scrum Guide: „The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. […] The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.“</p></div><p>Die PBIs für die nächsten zwei Sprints sollten deshalb „Sprint-ready“ sein und alle Informationen enthalten, die für die Implementierung notwendig sind, etwa Abnahmekriterien, Akzeptanztests oder UI-Entwürfe. Ferner dürfen die Items nur so groß sein, dass sie gemeinsam mit einigen anderen Items innerhalb eines Sprints entsprechend der Definition of Done umgesetzt werden können. Dabei greifen Product Owner gegebenenfalls auf Techniken wie das Story Splitting zurück, um zu große Items in kleinere zu zerlegen.</p><p>Anforderungen, die erst später oder eventuell gar nicht umgesetzt werden, weil sich die Rahmenbedingungen geändert oder neue Erkenntnisse ergeben haben, werden im Backlog nur als Idee vorgemerkt. In die Ausarbeitung dieser Ideen stecken Product Owner dann aber keine Energie, getreu dem Motto einer „Just-in-time Specification“. Der Vorteil dieser Herangehensweise ist, dass sich unklare Anforderungen, Annahmen und Hypothesen zunächst anhand von echtem Kundenfeedback prüfen lassen, bevor Aufwand in die Spezifikation fließt.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Lesen Sie auch</header><div class=„a-boxtarget a-boxcontent“ data-collapse-target=„“><article class=„a-article-teaser a-article-teaser–horizontal-layout article-teaser–articlebox a-u-no-margin-bottom a-theme“ data-cid=„0“><a class=„a-article-teaserlink“ href=„https://www.heise.de/news/Dritter-Product-Owner-Day-geplant-Referenten-koennen-sich-ab-sofort-bewerben-6072147.html“ name=„meldung.newsticker.inline.article-teaser.1“ title=„Dritter Product Owner Day geplant: Referenten können sich ab sofort bewerben“><figure class=„a-article-teaserimage-container“><div><strong><img alt=„“ height=„658“ src=„https://static.wallabag.it/7862d1b7aff4c3b00f37212fefade4e0e2c4cf00/64656e6965643a646174613a696d6167652f7376672b786d6c2c253343737667253230786d6c6e733d27687474703a2f2f7777772e77332e6f72672f323030302f7376672725323077696474683d273639367078272532306865696768743d2733393170782725323076696577426f783d2730253230302532303639362532303339312725334525334372656374253230783d273027253230793d27302725323077696474683d27363936272532306865696768743d273339312725323066696c6c3d27253233663266326632272533452533432f726563742533452533432f737667253345/“ class=„c1“ width=„1172“ referrerpolicy=„no-referrer“ /></strong></div></figure><div class=„a-article-teasercontent-container“><header><h1 class=„a-article-teasertitle a-u-mb-1“><strong>Dritter Product Owner Day geplant: Referenten können sich ab sofort bewerben</strong></h1></header></div>[2]</a></article></div><p>Product Owner sind wiederum auch für alle Entscheidungen verantwortlich, die sich im Product Backlog widerspiegeln. Das Product Backlog ist die einzige Anforderungsquelle, alle Anforderungen sind in diesem zentralen Scrum-Artefakt enthalten. Ausschließlich an ihr orientieren sich die Developer. Dabei sollten Product Owner auch stets prüfen, ob ihre Einschätzung des Business Value der einzelnen PBIs noch passt. Dafür eignen sich die verschiedenen <a href=„https://www.scrum.org/resources/evidence-based-management“ rel=„external noopener“ target=„_blank“><strong>Metriken, die im Evidence Based Management beschrieben sind [3]</strong></a>.</p><p>Nicht alle PBIs wie User Stories müssen Product Owner selbst schreiben. Sie können sich von Mitgliedern des Entwicklungsteams oder von den Stakeholdern helfen lassen. Oft unterstützen Business-Analysten den Product Owner[A1] [A2], die Stories zu schreiben, weil eine Person allein dies für Produkte mit komplexer Fachlichkeit kaum bewältigen kann. Die Helfer arbeiten sich in die Details der Story ein, der Product Owner behält den Überblick. Aber die Entscheidungshoheit und die Priorisierung des Backlogs bleiben weiterhin die Aufgabe des Product Owners.</p><h3 class=„subheading“ id=„nav_hut_des4“>Hut des User-Experience-Experten</h3><p>Als Experten für User Experience (UX) stellen Product Owner sicher, dass das Produkt die Bedürfnisse und Wünsche seiner Anwenderinnen und Anwender befriedigt und ihnen einen Mehrwert bringt.</p><figure class=„a-u-inline-left a-inline-image a-u-inline“><div></div></figure><p>Damit das Produkt am Markt erfolgreich ist, muss es die Kundenbedürfnisse erfüllen. Daher ist es als Product Owner essenziell, die Wünsche und Bedürfnisse der Kunden, die das Produkt einsetzen, genau zu kennen. Entsprechend gilt es, die zukünftigen Kunden und ihre Bedürfnisse zu identifizieren. Mittels UX-Methoden entwickeln Product Owner die notwendige Empathie für ihre Kundinnen und Kunden, sodass sie stellvertretend für sie sprechen können. Für den weiteren Verlauf der Produktentwicklung erarbeiten die Product Owner unter anderem Personas und Customer Journey Maps, damit die Kundenbedürfnisse der wichtigsten Nutzergruppen für alle Beteiligten permanent präsent sind</p><p>In regelmäßigen Reviews und Usability Tests sammeln Product Owner das notwendige Feedback ein und lassen es in die Produktentwicklung einfließen. Zum Nachvollziehen der Kundenzufriedenheit setzen Product Owner geeignete Metriken ein und passen ihr Vorgehen gegebenenfalls an. Auch können sie Elemente zur Kundeninteraktion direkt in das Produkt integrieren, etwa Feedback-Möglichkeiten oder Monitoring-Mechanismen.</p><p>Dabei sind Product Owner aber nicht auf sich allein gestellt, sondern sie können sich Hilfe von UX-Experten holen. Sinnvollerweise gehören deshalb auch sie zu den cross-funktionalen, interdisziplinären Scrum-Teams. Als Experten für die User Experience unterstützen sie dann nicht nur bei der Entwicklung von anwenderfreundlichen Bedienoberflächen, Workflows und Styleguides, sondern helfen Product Ownern auch, die Kunden und ihre Bedürfnisse zu verstehen, sie während der Entwicklung transparent zu halten und Feedback einzuholen.</p><h3 class=„subheading“ id=„nav_hut_des_leaders_5“>Hut des Leaders</h3><p>Als Leader geben Product Owner die Richtung der Produktentwicklung vor, inspirieren und motivieren das Scrum-Team, das Produktziel zu verwirklichen. Sie evaluieren und kommunizieren aktiv den Fortschritt der Produktentwicklung.</p><figure class=„a-u-inline-left a-inline-image a-u-inline“><div></div></figure><p>Damit ein Produkt erfolgreich entwickelt werden kann, brauchen Product Owner ein gut funktionierendes Team. Daher sind sie für die Zusammenstellung des Teams selbst zuständig. Außerdem tragen sie dafür Sorge, dass das Scrum-Team das Produktziel, das aktuelle Produkt, die Roadmap und die Kunden des Produkts kennt. Indem Product Owner das gesamte Scrum-Team einbeziehen, kann sich jedes Teammitglied als Teil von etwas Größerem fühlen, kennt den Zweck und das Ziel seiner Aufgaben und weiß, wohin die gemeinsame Reise gehen soll. Hierdurch kann jeder im eigenen Arbeitsbereich die besten Entscheidungen treffen, um das Produktziel Schritt für Schritt umzusetzen. Das schafft ein motivierendes Arbeitsumfeld für die Developer.</p><p>Product Owner behalten den Fortschritt der Produktentwicklung im Auge und klären ab, wie viel Arbeit für das gesetzte Ziel noch zu leisten ist. Sie nehmen Reporting-Aufgaben wahr und informieren die Stakeholder wie auch das Management ihres Unternehmens über den Status der Produktentwicklung.</p><header class=„a-boxheader“ data-collapse-trigger=„“>Agile Leader Day 2021: Konferenz und Workshops für agile Führungskräfte</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent“ data-collapse-target=„“><figure class=„a-inline-textboximage-container“><img alt=„“ class=„float-center c2“ src=„https://heise.cloudimg.io/width/1254/q50.png-lossy-50.webp-lossy-50.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/Screenshot_2021-06-17_102919-370803c90c22ec03.jpg“ srcset=„https://heise.cloudimg.io/width/2508/q30.png-lossy-30.webp-lossy-30.foil1/_www-heise-de_/imgs/18/3/1/2/2/3/2/7/Screenshot_2021-06-17_102919-370803c90c22ec03.jpg 2x“ referrerpolicy=„no-referrer“ /></figure><div class=„a-inline-textboxcontent-container“><p>Als Erweiterung der Product Owner Days richten <em>heise Developer</em> und <em>dpunkt.verlag</em> <a href=„https://ald.inside-agile.de/“ rel=„external noopener“ target=„_blank“><strong>am 24. Juni 2021 den ersten Agile Leader Day (online) [4]</strong></a> aus. Wer teilnimmt, erfährt</p><ul class=„boxtitel“><li>wie man selbstorganisierte Teams im Gegensatz zu Einzelpersonen führt,</li><li>wie man Mitarbeiter beurteilt (wenn die Teamleistung im Vordergrund steht) und</li><li>in welcher Menge und Form es dann noch disziplinarisches Führen braucht.</li></ul><p>Zielgruppe sind die Leiterinnen und Leiter von Gruppen, Teams oder Abteilungen sowie erfahrene Scrum Master und Agile Coaches. Einzeln oder im Team können sie rings um den Online-Konferenztag auch <a href=„https://ald.inside-agile.de/#workshops“ rel=„external noopener“ target=„_blank“><strong>in Workshops ihr Wissen praktisch vertiefen [5]</strong></a>.</p></div></div><h3 class=„subheading“ id=„nav_hut_des6“>Hut des Entscheiders</h3><p>Als Entscheider hat der Product Owner das Sagen über alle Aspekte, die das Produkt und dessen Entwicklung betreffen – aus inhaltlicher wie aus wirtschaftlicher Sicht.</p><figure class=„a-u-inline-left a-inline-image a-u-inline“><div></div></figure><p>Product Owner sind für das Produkt und dessen Erfolg verantwortlich. Damit sind sie auch diejenigen, die die Entscheidungen für die Produktentwicklung treffen. Die gesamte Unternehmensorganisation sowie auch die Stakeholder müssen hinter dem Product Owner stehen, ihm das Mandat geben, die inhaltlichen und wirtschaftlichen Entscheidungen zu treffen. Nur so können Product Owner das volle Potenzial ihrer Rolle entfalten. Wenn Product Owner etwa wegen fehlender Budgetverantwortung nicht befugt sind, Entscheidungen zu treffen und zunächst Gremien wie Lenkungsausschüsse kontaktieren müssen, gerät die gesamte Entwicklung des Produkts ins Stocken. Entsprechend sinkt womöglich die Effizienz der Developer, weil sie nicht am aktuellen Thema weiterarbeiten können und somit die weitere Entwicklung blockiert ist.</p><h5 id=„nav_akzeptanzkriteri7“>Akzeptanzkriterien formulieren</h5><p>Auch wenn sich Stakeholder nicht einigen können oder es mehrere Entwicklungsalternativen gibt, bestimmen Product Owner, was entwickelt wird und was nicht. Über Akzeptanzkriterien definieren sie, was sie bei der Umsetzung eines PBIs erwarten und was nicht. Den Developern geben sie Feedback über die abgelieferte Arbeit und zeigen den Weg auf, der noch zu gehen ist. Sie evaluieren mit jeder Iteration die Produktentwicklung und entscheiden, ob das Produktinkrement veröffentlicht wird.</p><p>Alle Entscheidungen eines Product Owners sind durch die Sortierung des Product Backlogs transparent. Die ganze Unternehmensorganisation muss diese Entscheidungen respektieren und darf nicht versuchen, Mitglieder des Scrum-Teams dazu zu bringen, an etwas anderem als dem Backlog zu arbeiten. Falls ein Stakeholder Änderungen am Backlog wünscht, muss dieser den Product Owner überzeugen, weil er die Entscheidungshoheit über das Product Backlog trägt.</p><h3 class=„subheading“ id=„nav_hut_des8“>Hut des Teammitglieds</h3><p>Als Teil des Scrum Teams arbeiten Product Owner gemeinschaftlich mit den anderen Teammitgliedern daran, innerhalb der Sprints ein wertvolles Produktinkrement zu erarbeiten und gemeinsam kontinuierlich besser zu werden.</p><figure class=„a-u-inline-left a-inline-image a-u-inline“><div></div></figure><p>Um das zu erreichen, halten sich Product Owner an das Scrum-Framework, leben die Scrum-Werte und greifen auf das empirische Vorgehen zurück, um neue Erkenntnisse in die Produktentwicklung einfließen zu lassen. Sie respektieren die Selbstorganisation (engl. self-management) der Developer und des gesamten Scrum Teams. Sie nutzen das Coaching und die Unterstützung des Scrum Masters hinsichtlich Scrum, Product-Backlog-Techniken und der empirischen Produktentwicklung sowie seine Hilfe bei der Organisation von Scrum-Events. Product Owner helfen auch dabei, Hindernisse zu beseitigen – unabhängig davon, ob sie das Scrum Team, die Organisation oder den Markt und die Kunden betreffen. Sie sehen sich nicht als Proxy zwischen Developern und Stakeholdern, sondern als „Matchmaker“. Ziel des Matchmakings ist es, dass die Developer mit den Stakeholdern effektiv zusammenarbeiten können, um einerseits das Feedback und andererseits den Product Value zu maximieren.</p><p>Damit im Sprint ein wertsteigerndes Produkt entsteht, definieren die Product Owner im Sprint Planning gemeinsam mit den Developern das Sprintziel. Zu diesem Zeitpunkt stellen Product Owner sicher, dass das Scrum-Team das Sprintziel, das Produktziel sowie wichtige Informationen zur Produktentwicklung kennt. Sie sind dafür verantwortlich, dass den Developern ausreichend fertige PBIs bereitstehen, um das Sprint Backlog zu füllen und eine Vorhersage für den Sprint abgeben zu können. Während des Sprints klären sie gegebenenfalls aufkommende Fragen zu den PBIs und geben Feedback zu den bereits umgesetzten. Notfalls verhandeln sie den Scope (Funktionsumfang) neu oder akzeptieren Abstriche beim Sprint.</p><h5 id=„nav_sprint_review9“>Sprint Review mit den Stakeholdern</h5><p>Zur Sprint Review laden Product Owner die Stakeholder ein. Die Absicht dabei ist, konstruktives Feedback zur aktuellen Produktentwicklung zu erhalten und die nächsten Entwicklungsschritte aufzuzeigen. Der aktuelle Zustand und die Sortierung des Backlogs stehen während des Sprint Reviews zur gemeinsamen Diskussion. Gemeinschaftlich überlegen das Scrum-Team und die Stakeholder auch, wie sich der Wert des Produkts zukünftig für Kunden und Unternehmen noch weiter steigern lässt. Dieses wertvolle Feedback lassen Product Owner schnellstmöglich in das Product Backlog einfließen. Insbesondere Feedback und Änderungen, die die Spitze des Backlogs betreffen, müssen sie unverzüglich und noch vor dem Beginn des nächsten Sprints einarbeiten.</p><p>In der Sprint-Retrospektive erarbeiten Product Owner gemeinsam mit den anderen Mitgliedern des Scrum Teams Maßnahmen, um sich als Team kontinuierlich zu verbessern. Sinnvollerweise planen sie in jeder Sprint-Retrospektive für jede der Scrum-Rollen, also Scrum Master, Product Owner und Developer, eine konkrete Verbesserungsmaßnahme für den nächsten Sprint ein. Hilfreiche Beispielfragen sind: „Funktioniert die Kommunikation im Team gut?“, „Ist der Product Owner ausreichend oft verfügbar?“, „Lassen sich die PBIs noch besser beschreiben?“ oder „Sind andere als die angewandten Methoden zielführender?“</p><p>An den Dailys müssen Product Owner nicht teilnehmen. Sie bieten ihnen aber eine gute Möglichkeit, sich über den aktuellen Stand der Entwicklung und womöglich aufkommende Probleme oder Fragestellungen zu informieren. Hierdurch können sie schnell Feedback geben und eingreifen, falls die Entwicklung eines PBIs in eine andere Richtung läuft als vorgesehen.</p><h5 id=„nav_schätzen_und10“>Schätzen und Verfeinern von Product Backlog Items</h5><p>In Refinement- und Estimation-Aktivitäten präsentieren Product Owner neue PBIs und Erkenntnisse. Sie stellen damit sicher, dass alle Teammitglieder die bevorstehenden Aufgaben verstanden haben. Fragen und offene Punkte klären sie gemeinsam, damit das Team eine Gelegenheit für Rückfragen hat. Durch die Diskussion finden die Developer geeignete Lösungsideen und können sinnvolle Aufwandschätzungen abgeben. Gleichzeitig erhalten Product Owner Kenntnis über Risiken oder Abhängigkeiten, die sie in das Product Backlog einarbeiten müssen. Eine grobe Schätzung des gesamten Backlogs durch die Developer hilft Product Ownern außerdem bei der Releaseplanung.</p><p>Product Owner aktualisieren das Product Backlog zeitnah mit allen neuen Informationen und Erkenntnissen, sodass es jederzeit den aktuellen Wissens- und Planungsstand widerspiegelt. Hierdurch ist für jedes Mitglied des Scrum Teams sowie für die Stakeholder ersichtlich, wie die geplante Reise der Produktentwicklung aussieht und was als Nächstes ansteht.</p><h3 class=„subheading“ id=„nav_product_owner11“>Product Owner tragen Verantwortung – müssen aber nicht alles alleine stemmen</h3><header class=„a-boxheader“ data-collapse-trigger=„“>Santa Clause Rule: Team Spirit</header><div class=„a-boxtarget a-boxcontent a-inline-textboxcontent a-inline-textboxcontent-container“ data-collapse-target=„“><p>„Santa Clause Rule: No matter how busy Santa gets, he does not bring on other Santas. How does he cope?“</p><p>- Elves</p></div><p>Product Owner tragen die Verantwortung für den Produkterfolg und haben zahlreiche damit verknüpfte Aufgaben zu bewältigen. Je größer und komplexer ein Produkt wird, desto häufiger müssen sich Product Owner helfen lassen, um den Blick auf das Wesentliche richten zu können. Indem sie taktische Tätigkeiten wie das Schreiben von User Stories oder Rechercheaufgaben delegieren, können sie sich auf strategische Aspekte des Value-driven-Development konzentrieren. Damit kommen sie ihrer wichtigsten Aufgabe nach: den Product Value zu maximieren.</p><p>Der Auftrag des Product Owners bleibt es dabei immer, die Verantwortung für das Produkt und dessen Erfolg zu übernehmen, die Richtung vorzugeben und die notwendigen Entscheidungen zu treffen. Aber je strategischer Product Owner unterwegs sind, desto stärker müssen sie auch darauf achten, nicht die Tuchfühlung zum Scrum Team zu vernachlässigen, sondern mit dem Team eng in Kontakt zu bleiben.</p><p><em>Dipl.-Ing. Cornelia Seraphin<br /></em> <em>arbeitet seit über 15 Jahren im Software Engineering. Als Senior Business Consultant bei der msg leitet sie das Center of Competence Business Analysis, führt Anforderungsanalysen durch und begleitet Projekte als Product Owner. Ihr Wissen gibt sie unter anderem in Schulungen weiter, etwa in der zum Certified Professional Scrum Product Owner.</em></p><p>() </p><hr /><p><strong>URL dieses Artikels:</strong><br /><small><code>https://www.heise.de/-6072808</code></small></p><p><strong>Links in diesem Artikel:</strong><br /><small><code><strong>[1]</strong> https://scrumguides.org/</code></small><br /><small><code><strong>[2]</strong> https://www.heise.de/news/Dritter-Product-Owner-Day-geplant-Referenten-koennen-sich-ab-sofort-bewerben-6072147.html</code></small><br /><small><code><strong>[3]</strong> https://www.scrum.org/resources/evidence-based-management</code></small><br /><small><code><strong>[4]</strong> https://ald.inside-agile.de/</code></small><br /><small><code><strong>[5]</strong> https://ald.inside-agile.de/#workshops</code></small><br /><small><code><strong>[6]</strong> mailto:sih@ix.de</code></small><br /></p><p class=„printversioncopyright“><em>Copyright © 2021 Heise Medien</em></p> </html>
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International