Du bist Product Owner (PO) und bei deinem Produkt läuft es richtig gut: die Stakeholder sind von deiner Vision begeistert, du kannst dich vor neuen Ideen kaum noch retten, deine Roadmap ist bis Ende nächstes Jahr voll. Perfekt, oder?

Fast… wäre da nicht die schleichende wachsende Unzufriedenheit des Entwicklungsteams. Die Backlog Items sind immer öfter nicht ausreichend spezifiziert und müssen im Sprint selbst erstmal detailliert werden. Das Gefühl, das es nicht ganz rund läuft macht sich langsam aber sicher breit.

Kommt dir die Situation bekannt vor?

Falls ja, ist es für dich und dein Team Zeit, um über den Einsatz eines Business Analysten (BA) nachzudenken. Die folgenden Überlegungen können auch für dich nützlich sein, wenn du bereits mit Business Analysten arbeitest und die Zusammenarbeit verbessern möchtest. 

Überlegung #1: die Ursache für die mangelnde Spezifizierung aufdecken

Klartext voraus: BAs sind kein Ersatz für einen guten PO. Deshalb ist es so wichtig den wahren Grund der mangelnden Spezifizierung der Backlog Items herauszufinden. Die Aussage „Zu wenig Zeit“ ist kein Grund, sondern oft nur eine oberflächliche Wahrnehmung. Die Ursache kann in einem oder mehreren Aktivitätsbereichen liegen: 

Fehlende Kompetenz

Niemand wird als PO geboren und kein Team funktioniert genau wie ein Anderes. Deshalb sind fehlende Kompetenzen eher die Regel als die Ausnahme. Sobald du es aber erkannt hast, kannst du etwas dagegen unternehmen. Bezüglich der mangelhaften Spezifizierung gibt es zwei Möglichkeiten: du und dein Team teilen nicht das gleiche implizite Verständnis über die Anforderungen oder/und du hast noch nicht gelernt, wie man Anforderungen detailliert aufnimmt. Um das gemeinsame Verständnis zu verbessern, braucht es Zeit und viele Fragen. Zögere nicht vermeindliche Selbstverständlichkeiten explizit zu machen und dem Entwicklungsteam viele Fragen zu deren Verständnis und Bedürfnissen zu stellen. Im Gegenzug sollte das Entwicklungsteam dir auch Fragen zum Kontext und der geschäftlichen Notwendigkeit der Anforderungen stellen. Schritt für Schritt werdet ihr euch so annähern. Deine Requirements Engineering Kompetenz kannst du durch die Teilnahme an Schulungen, Trainings und Konferenzen steigern. 

Stakeholder Geflecht

In manchen Organisationen ist das Stakeholder Geflecht sehr weitläufig und verstrickt. Als PO solltest du alle deine Stakeholder kennen und deren Bedürfnisse und Wünsche gut einschätzen können. Mit einer steigenden Anzahl an Stakeholdern steigt nicht nur die Anzahl der Gespräche, die du führen solltest, sondern auch die Wahrscheinlichkeit an Konflikten und divergierenden Interessen. Auch nach Einführung diverser Optimierungsmaßnahmen in deinem Stakeholder Management reicht deine Arbeitszeit schlicht weg nicht mehr aus, um sowohl die Bedürfnisse tief gehend zu verstehen, als auch die komplexen Verhältnisse diplomatisch anzugehen. 

Komplexität der Fachanforderung

Dein Produkt ist Teil eines größeren Geschäftsprozesses und es gibt zahlreiche fachliche Abhängigkeiten. Jede scheinbar einfache Anforderung bedarf eine grundlegende Analyse um Ausnahmen, Abhängigkeiten und Wechselwirkungen sorgfältig erfassen zu können. Auch wenn du richtig gut und gerne diese Aufgabe übernimmst, ist sie zeitintensiv und du kommst einfach nicht mehr hinterher. 

Komplexe Randbedingungen

Als ob die ersten drei Gründe nicht ausreichend wären – Randbedingungen können dir deine Arbeit deutlich erschweren. Wenn dein Produkt komplexen technischen Vorgaben unterliegt, musst du für jede Anforderung die dazugehörige Konformität validieren. Da du als PO nicht zwingend einen technischen Background hast, kann es für dich besonders knifflig werden dies ohne weitere Unterstützung zu überprüfen.

Je klarer du die Ursache des Problems identifizieren kannst, desto einfacher kannst du im nächsten Schritt das passende BA Profil definieren.

Überlegung #2: den passenden Business Analysten einsetzen 

BA ist nicht gleich BA. Die Tätigkeit des Business Analysten hat zahlreiche Facetten, die mal mehr mal weniger benötigt werden und sehr unterschiedliche Kompetenzen erfordern. Um dich als PO effizient in der Spezifizierung der Anforderungen zu unterstützen, sollte der BA ein doppeltes Grundverständnis haben (oder sich schnell aneignen können). Ein Grundverständnis für die Stakeholder und deren Bedürfnisse sowie ein Grundverständnis für das Produkt und dessen Technologie. Darüber hinaus können die Schwerpunkte in drei grobe Profile zusammengefasst werden:

Funktionale Analysten haben eine Vorliebe für das Business. Sie sprechen die Sprache der Stakeholder, decken Konflikte auf, verstehen die Prozesse und deren Grenzfälle und bringen leidenschaftlich Struktur und Klarheit in die fachlichen Anforderungen. 

Technische Analysten haben eine Vorliebe für die im Produkt eingesetzte Technik. Sie verstehen die technischen Zusammenhänge und Möglichkeiten und fühlen sich den Entwicklern verbunden.

„Proxy PO“ Analysten fühlen sich in der Breite der PO Aufgaben wohl und können komplette Bereiche übernehmen.

Nicht jedes Profil passt zu jedem Problem. Folgende Kombinationen in deren reinster Form sind eher ein Glückstreffer. Nichts desto trotz können sie dir eine Orientierung geben: 

• Zu einem komplexen Stakeholder Geflecht passt ein „Proxy PO“ Analysten Profil. In dieser Kombination solltest du als PO besonders darauf achten, dass du und dein BA gut harmonieren. Auch wenn die Aufteilung der Themen (und nicht der Aufgaben) eine Vorstufe für eine zukünftigen Skalierung sein kann, ist diese es noch nicht. Darum solltet ihr gemeinsam sicherstellen nur mit einer Stimme zu sprechen. Der Einstieg als „Proxy PO“ Analyst eignet sich gut, um Erfahrung in den PO Aufgaben zu sammeln, also als „training on the job“. 

• Zu komplexen Fachanforderungen passt ein funktionales BA Profil. Das Ermitteln der erwünschten Detaillierungstiefe kann zu einer sehr engen Zusammenarbeit zwischen BA und Stakeholder führen und für ein starkes Vertrauensverhältnis sorgen. Zwischen PO und BA sollte dementsprechend eine klare Absprache bzgl. der Bewertung der Priorisierung getroffen werden.

• Zu komplexen Randbedingungen passt ein technisches BA Profil. In dieser Kombination ist es wichtig darauf zu achten, nicht das gemeinsame Ziel aus den Augen zu verlieren. Es kann leicht passieren, dass Randbedingungen und Produkt Vision kollidieren. Es obliegt der Verantwortung des BAs dem PO Alternativen aufzuzeigen und eine Differenzierung zwischen „historisch gewachsenen” und „fachlich notwendigen“ Randbedingungen zu machen. Diese Auseinandersetzung sollte nicht konfrontativ, sondern konstruktiv geführt werden.

Überlegung #3: den Austausch aufrecht halten und den Bedarf regelmäßig überprüfen

Um die Zusammenarbeit optimal zu gestalten, sollten die Aufgaben zwischen PO und BA klar aufgeteilt werden. Eine klare Aufteilung der Aufgaben ermöglicht eine zielstrebige Umsetzung der unterschiedlichen Tätigkeiten und das Einsetzen der richtigen Kompetenz zum besten Zeitpunkt. Diese Aufteilung sollte aber nicht als endgültig betrachtet werden, sondern nach Bedarf angepasst werden. Deshalb ist ein reger Austausch zwischen Business Analyst(en) und Product Owner ein wesentliches Element der erfolgreichen Teamerweiterung. 

Wenn du dir unsicher bist, wie du diese Kommunikation initiieren und aufrecht halten kannst, frag mal bei deinem Scrum Master nach.

Nachdem diese etabliert ist, lassen sich neue Herausforderungen, wie eine neue Orientierung des Produkts, eine Skalierung oder eine Verkleinerung des Teams, besser bewältigen!