Agile Softwareentwicklung: Die vielen Hüte der Product Owner
Seite 2: Hut des Requirements Engineers
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.
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.
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.
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.
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."
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.
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.
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 Metriken, die im Evidence Based Management beschrieben sind.
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.
Hut des User-Experience-Experten
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.
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
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.
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.