Das Universum des Product Owners
Sehr oft wird (vor allem in Scrum-lastiger Literatur) die Arbeit des Product Owners mit der Pflege des Product Backlogs gleichgesetzt. req42 geht deutlich darüber hinaus.
Agiles Requirements Engineering ist viel mehr als nur das Product Backlog managen.
Natürlich ist das Product Backlog das wichtigste Artefakt zum Managen von Anforderungen in agilen Teams. Dabei wird aber oft übersehen, dass Sie als Product Owner sich auch noch um weitere Dinge kümmern müssen. Zum Beispiel sollten Sie schriftlich festgehaltene Ziele haben, damit nicht jeder im Projekt von anderen Zielen träumt. Natürlich sollten alle eine gemeinsame Sprache sprechen, denn wenn jeder über andere Dinge spricht, dann besteht die große Gefahr von Kommunikationsproblemen im Team.
Um Ihnen als Product Owner die Gesamtheit der von Ihnen zu verwaltenden Dinge (neudeutsch: Artifacts) aufzuzeigen haben wir als Metapher das Universum gewählt, oder besser den Teil des Universums, der Sie als Product Owner betrifft. Im Zentrum Ihres Universums steht der Product Backlog als eines Ihrer wichtigsten Arbeitsinstrumente. Um dieses Zentrum herum kreisen jedoch viele andere Artefakte, die agiles Requirements Engineering erst erfolgreich machen (vgl. Abb. 1).
Kein Dokument, sondern einfach geordnetes Wissen
Wir hoffen, dass diese Metapher Sie davon abbringt, dass Sie all diese Artefakte in Form eines Dokumentes verwalten müssen. Sie sollten diese Artefakte nur in irgendeiner Form greifbar haben, die es allen beteiligten Stakeholdern ermöglicht, darüber vernünftig zu kommunizieren.
Erinnern Sie sich an unseren Farbcode, den wir auf www.req42.de eingeführt haben? Wenn nicht – zur Auffrischung nochmals: rot sind die Dinge Ihres Universums, die hauptsächlich managementorientiert sind, blau sind die requirementsrelevanten Dinge und grün sind die Ergebnisse des Entwicklungsteams.
Da Sie als Product-Owner eine Mischung aus Manager und Business Analyst/Requirements Engineer sind, besteht Ihr Universum hauptsächlich aus roten und blauen Planeten.
1 - Das
Product Backlog:
Der Scrum Guide [1] definiert: „Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient die einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich.
Ein Product Backlog ist niemals vollständig. Während seiner ersten Entwicklungsschritte zeigt es die anfangs bekannten und am besten verstandenen Anforderungen auf. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Es ist dynamisch; es passt sich konstant an, um für das Produkt klar herauszustellen, was es braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerb zu bestehen und den erforderlichen Nutzen zu bieten.“
So lange ein Produkt existiert, existiert auch sein Product Backlog.
Sie sehen also: das Product Backlog ist wirklich wichtig für die erfolgreiche Arbeit als Product Owner. Aber bitte lesen Sie weiter. Ihr Job fängt vielleicht nicht mit dem Product Backlog an und hört sicherlich nicht mit dem Product Backlog auf.
2 - Das Ergebnis der Iterationen:
Product Increments
Die Product Increments werden vom Entwicklungsteam erzeugt. Bei IT-Systemen sollten diese Inkremente „potentiell auslieferbare Teilsysteme“ mit allem Drum und Dran (Dokumentation, Release Notes, Installationsanweisungen, …) sein.
Aufgabe des Product Owners ist es, diese Zwischenergebnisse jeweils am Ende einer Iteration abzunehmen, d.h. zu beurteilen, ob die Anforderungen, die in diesem Zeitraum umgesetzt werden sollten, auch tatsächlich (entsprechend der Definition of Done – DoD) erledigt wurden.
Falls nicht, müssen vielleicht neue Anforderungen in das Product Backlog eingefügt werden.
3 -
Die managementorientierten Artefakte
Als Product Owner sind Sie nicht nur dafür verantwortlich, Ihr Entwicklungsteam kontinuierlich mit Requirements zu versorgen, sondern auch für die Zielausrichtung, die Planung, kontinuierliches Wert- und Risikomanagement und Priorisierung. Das alles natürlich unter optimaler Nutzung der Mittel („Assets“), die man Ihnen dafür zur Verfügung stellt.
Sie werden also neben dem Produkt-Backlog noch einer Reihe von Informationen verwalten, die wir Ihnen in den folgenden Absätzen etwas näherbringen wollen.
3.1 -
Assets
(dt.: Kapital, Vermögen, …)
Unter „Assets“ fassen wir das zusammen, was Ihnen Ihre Auftraggeber oder Chefs mitgeben, um Sie als Product Owner (zusammen mit Ihrem Team) zu befähigen, Ihren Job erfolgreich auszuführen.
Die Assets schließen auf jeden Fall Zeit und Budget ein, d.h. Mittel, die man Ihnen für Ihre Aufgabe zur Verfügung stellt. Vielleicht müssen Sie sich Ihr Team mit diesen Mitteln selbst besorgen oder man stellt Ihnen auch Personal (Ihr Team), Arbeitsräume, Infrastruktur, etc. zur Verfügung.
Wenn Sie den Job als Product Owner übernehmen, dann müssen Sie über diese Assets mit Ihren Auftraggebern verhandeln und sicherlich im Endeffekt über deren Verwendung auch (durch hoffentlich erfolgreiche Ergebnisse) Rechenschaft ablegen.
Auf jeden Fall sollten Sie wissen, was Ihnen an Geld, Personal, Zeit, Infrastruktur, … zur Verfügung steht. Diese Assets sind eine wesentliche Randbedingung für Ihre Arbeit als Product Owner.
3.2 -
Business Goals
(dt.: Vision, Ziele, …)
Vielleicht haben Ihnen Ihre Auftraggeber grobe Ziele oder eine Vision mitgegeben, als man Sie mit der Rolle des Product Owners betraut hat. Oft reicht jedoch die Präzision dieser Vorgaben nicht aus, um ein Team systematisch zum Erfolg zu führen.
Es gehört zu Ihren Aufgaben, die Ziele soweit zu präzisieren und abzustimmen, dass alle Beteiligten eine klare Vorstellung davon haben, was in welchen Zeiträumen erreicht werden soll.
Für uns gilt: Ziele sind Anforderungen! Oder präziser: Ziele sind die Anforderungen, die sich hoffentlich in dem Zeitraum, für die sie definiert sind, nicht andauernd ändern.
Zur Definition von Zielen zeigen wir Ihnen in unseren Trainings mehrere Varianten (PAM, Produktkoffer, News from the Future, Product Canvas, Value Propositions, …), die Sie nach Lust und Laune wählen können. Nur eines sollten Sie nie machen: Ohne explizite Ziele oder Visionen zu arbeiten.
3.3 -
Roadmaps
(dt. grober Entwicklungsfahrplan, Projektplan, …)
Auch agile Projekte brauchen einen Plan. Je weiter ein Ziel in der Ferne liegt, desto ungenauer kann der Plan sein. Je näher, desto genauer.
Eine explizit bekannte Roadmap ermöglicht allen Beteiligten mittelfristig mitzudenken und daher bei kurzfristigen Entscheidungen zu berücksichtigen, was da noch alles kommen wird. Wenn Sie nur von der Hand in den Mund leben, treffen Sie unter Umständen unwissentlich kurzfristig Entscheidungen, die dem längerfristigen Produkterfolg entgegenstehen. In unseren Kursen zeigen wir Ihnen, wie grob oder fein eine Roadmap sein kann, darf oder sollte.
3.4 -
Teams
(dt.: Teamstruktur)
Sollte Ihnen mehr als ein Team zur Verfügung stehen, so ist es selbstverständlich, dass Sie einen Überblick haben sollten, wer in welchem (Teil-)Team arbeitet und wie diese Teams organisiert sind. Grundsätzlich gilt heute, dass Sie „Conways Law“ nicht missachten sollten. Die Teamstruktur (also Ihre Organisationsstruktur) und die Produktstruktur sollten sich nicht widersprechen, sonst kann ein einzelnes Teilteam keine sinnvollen Ergebnisse liefern, ohne sich ständig mit allen anderen abstimmen zu müssen.
Mehr zur Kunst der sinnvollen Aufteilung in Teilteams und deren Koordination lernen Sie im Abschnitt „Skalierung“ und „Scaling Frameworks“ in unseren Kursen.
3.5 -
Risks/Assumptions
(dt.: Risikoliste und Annahmen)
„Risikomanagement ist Projektmanagement für Erwachsene“ sagt Tim Lister von der Atlantic Systems Guild . In diesem Sinne sollten Sie Ihre Risiken als Product Owner im Griff halten.
req42 gibt Ihnen die Mittel an die Hand, Risiken bewusst zu managen. Insbesondere beim Priorisierung Ihrer Anforderungen sollten Sie ausgewogen zwischen Business Value und Risk Reduct ion abwägen.
4 -
Weitere Requirements-orientierte Artefakte
Neben den managementorientierten Artefakten und dem zentralen Product Backlog lohnt es sich für Sie als Product Owner, bis zu sechs weitere Artefakte ständig im Griff zu haben.
4.1 -
Stakeholder
Stakeholder sind Ihre wichtigsten Quellen für Anforderungen. Deshalb sollten Sie diese kennen und (in Form von Stakeholder-Listen oder Stakeholder-Maps) transparent machen. Sie müssen wissen, wer davon Ihnen wobei helfen oder Sie in welcher Form behindern kann. Sie müssen wissen, wer welchen Einfluss hat – und bei unterschiedlichen Meinungen müssen Sie vermitteln oder entscheiden.
Ohne explizit identifizierte Stakeholder ist das alles schwierig.
4.2 -
Scope-Abgrenzung
Scope ist der Bereich, den Sie beeinflussen können. Im Gegensatz zu Ihrer Umgebung („Kontext“), zu der Sie sicherlich viele Schnittstellen haben, die Sie aber (normalerweise) nicht alleine entscheiden können, sondern oft verhandeln müssen.
Zur Darstellung der Scope-Abgrenzung gibt es viele verschiedene Ausdrucksmittel, aber eine gute Scope-Abgrenzung macht die Schnittstellen zum Kontext explizit (z.B. in Form von Ein- und Ausgaben, von angebotenen und benötigten Services, …)
req42 empfiehlt Ihnen mit dem Business-Scope zu beginnen und nicht zu früh den Product-Scope einzuschränken. Die Entscheidung über die Produktgrenze sollte eine bewusste Entscheidung sein.
Mehr über dieses unverzichtbare Thema lesen Sie im Blog-Beitrag „Scope ist nicht gleich Scope“ oder in [2]. In unseren Kursen üben Sie die Scope-Abgrenzung anhand einer realistischen Fallstudie. Oder wir machen das gemeinsam mit Ihnen anhand Ihrer Produkte in Form von Impuls-Workshops.
4.3 -
Quality Requirements
Unsere Erfahrung zeigt: Qualitätsanforderungen sind (leider) nicht nur in der agilen Welt immer noch heftig unterschätzt. Jeder will qualitativ gute Produkte und Services, aber nur wenige machen es explizit, was damit genau gemeint ist.
Einige Qualitätsanforderungen (wie Antwortzeiten) lassen sich vielleicht direkt zu einer Story dazuschreiben. Die große Mehrheit an Qualitätsanforderungen bezieht sich jedoch auf viele Kärtchen, wenn nicht sogar auf alle Kärtchen des Product Backlogs. Deshalb brauchen Sie als Product Owner irgendwo die Möglichkeit, die gewünschten Qualitäten Ihrer Produkte und Services zu spezifizieren.
Wir zeigen Ihnen (mit industrie-erprobten Checklisten), wie Sie rasch die wichtigsten davon identifizieren und mittelfristig in Form von Qualitätsbäumen mit Szenarien managen können.
4.4 -
Constraints
Auch (technologische und organisatorische) Randbedingungen sind Anforderungen. Und da sie oft für mehrere oder sogar alle funktionalen Anforderungen gelten, sind sie schwer in dem geordneten Product Backlog unterzubringen. Stellen Sie einfach sicher, dass alle Beteiligten diese Randbedingungen kennen und bei Bedarf Zugriff dazu haben.
4.5 -
Domain Terminology
In jedem Epic, Feature oder Story kommen Begriffe aus Ihrer Domäne vor. Diese Begriffe sollten allen Beteiligten klar sein. Und deshalb ist es wünschenswert, für ein Projekt oder eine Produktentwicklung ein Glossar solcher Begriffe zu haben. Stellen Sie sicher, dass alle Beteiligten eine gemeinsame Sprache sprechen – und im Zweifelsfall Zugriff auf vereinbarte Begriffsdefinitionen haben, statt in jedem Meeting wieder neue Wörter ins Spiel zu bringen.
4.6 -
Supporting Models
In der agilen Welt hat es sich weit verbreitet, Anforderungen in Form von Epics, Features oder Stories auf Kärtchen zu schreiben (oder in äquivalenter Form in Tools wie JIRA abzulegen).
Trotzdem wird die Kommunikation unter allen Beteiligten manchmal erheblich einfacher, wenn man zusätzlich auch die Hilfsmittel verwendet, die wir in den letzten Jahrzehnten zur Präzisierung der Umgangssprache kennengelernt haben. Scheuen Sie also nicht davor zurück, Skizzen von Flussdiagrammen, Aktivitätsdiagrammen, BPMN, Zustandsmodellen, Datenmodellen, UI-Prototypen, Mock-ups, … zu verwenden, wenn es die Kommunikation fördert.
Keine Angst: diese Modelle müssen nicht perfekt sein. Aber manchmal fördert eine grafische Visualisierung von den 15 Schritten eines Geschäftsprozesses das Verständnis besser als 15 Kärtchen.
Zusammenfassung:
req42 gibt Ihnen viele Freiheitsgrade, mit welchen Methoden Sie diese Artefakte erstellen sollten, welche Notationen Sie zur Kommunikation nutzen und wie Sie die Ergebnisse vielleicht toolgestützt verwalten können. Eines aber sollte Ihnen als Product Owner klar sein: Sie arbeiten nicht nur mit dem Product Backlog!
Literatur:
[1] Schwaber, K., Sutherland, J.: Der Scrum Guide, November 2017, www.scrumguide.org
[2] Hruschka, P., Starke, G.: Scope ist nicht gleich Scope, Java-Magazin 4/2019