Potenziale und Grenzen KI-gestützter Assistenzsysteme in der Product Owner Rolle – eine Empirische Fallstudie

Simeon Schulz, Ronja Brauchle, Lisa-Marie Nohl

Kurzfassung:

Ziel der Arbeit ist es herauszufinden, welches Potenzial künstliche Intelligenz bei der Arbeit eines Product Owners in der agilen Projektmanagement Methode Scrum hat. Dazu wurde eine empirische Fallstudie durchgeführt, die unterschiedliche Tools nach Effizienz, Qualität, Usability und Integration bewertet. Die Ergebnisse zeigten, dass KI Tools in die alltäglichen Prozesse eines Product Owners integriert werden können und häufig eine gute Grundlage schaffen. Die Rolle des Product Owners, das Kontextwissen und die menschliche Expertise können dabei jedoch nicht ersetzt werden, sondern die KI Tools bieten die Möglichkeit wiederkehrende Aufgaben zu automatisieren und den Product Owner zeitlich zu entlasten.

Einleitung

Nach einer Umfrage von Statista im September 2024 nutzt bereits jedes fünfte Unternehmen in Deutschland künstliche Intelligenz (KI) in der IT. Dabei wird die generative KI bei Aufgaben wie der Kundenkommunikation, Übersetzungen oder dem Verfassen von Unternehmensreports verwendet [1]. Künstliche Intelligenz (KI) gewinnt somit im Themengebiet der agilen Softwareentwicklung zunehmend an Bedeutung. Mit den stetig wachsenden Fähigkeiten von KI-Systemen erweitern sich auch deren Einsatzmöglichkeiten, insbesondere zur Unterstützung von Aufgaben im agilen Projektmanagement, wie der Product-Owner-Rolle [2]. Dabei stellt sich die Frage, in welchem Umfang KI-Tools Aufgaben des Product Owners übernehmen oder bei der Bewältigung typischer Herausforderungen unterstützen können und in welchen Bereichen menschliche Kompetenzen weiterhin unverzichtbar bleiben. Ziel dieses Papers ist es, diese Fragestellung anhand einer empirischen Fallstudie zu untersuchen und die Potenziale aufzuzeigen.

Theoretischer Hintergrund

Der Product Owner (PO) ist Teil von Scrum, einem Framework für agiles Projektmanagement [3]. Agilität ist ein flexibler, iterativer Ansatz, bei dem kleine, regelmäßige Releases im Vordergrund stehen, um kontinuierliche Verbesserung und Continuous Delivery zu ermöglichen [4]. Im agilen Projektmanagement wird dieser iterative Ansatz umgesetzt, wobei Zusammenarbeit, Flexibilität und Kundenfeedback zentral sind [4]. Das Framework Scrum bietet Artefakte, Rollen, Ereignisse und Verpflichtungen, um dies zu ermöglichen. In Scrum wird innerhalb eines Sprints, einer ein- bis vierwöchigen Arbeitsphase, ein funktionsfähiges Produktinkrement erstellt. Die Rolle PO umfasst die Aufgabenfelder Product Backlog Management, Stakeholder Management, Release Management und die Entwicklung einer Produktvision. Die Produktvision ist der übergeordnete Zweck des Produkts und dient der Orientierung für das gesamte Team. Der PO ist ergebnisverantwortlich für die Maximierung des Produktwerts [3]. Außerdem muss der PO weitgehend die Geschäfts-, Kunden- und Marktanforderungen analysieren [5].

Eine weitere zentrale Aufgabe des PO ist die Kommunikation mit den Stakeholdern. Diese sind die Interessensvertreter des entstehenden Produkts. Intern kann das z. B. die Geschäftsleitung sein, extern sind es Kunden oder Endverbraucher des Produkts. Eine enge Zusammenarbeit zwischen dem PO und den Stakeholdern ist notwendig, da diese kein aktiver Teil des Scrum Teams sind und somit keinen direkten Einfluss auf das Projekt nehmen können. Der PO agiert als Interessensvertreter der Stakeholder und bildet die Schnittstelle zwischen dem Scrum Team und den Stakeholdern [6]. Zusätzlich dazu haben die Stakeholder jedoch auch die Möglichkeit, den Prozess des Produkts zu erleben, indem sie am Sprint Review teilnehmen. Dort können sie direkte Rückmeldungen zu den Neuerungen geben; ob dabei vorgeschlagene Änderungen oder Wünsche der Stakeholder jedoch auch umgesetzt werden, entscheidet der Product Owner. Weitere Sprint Events erfolgen nur mit der Teilnahme des Scrum Teams, und die Stakeholder dürfen nicht teilnehmen [3].

Auch die Release Notes sind ein Kommunikationskanal für Neuerungen, die meist vom Product Owner erstellt werden und von den Stakeholdern eingesehen werden können. Dabei handelt es sich um einen technischen Bericht, der Updates zum Produkt enthält. Des Weiteren werden auch Bugfixes und neue Sicherheitsupdates darüber kommuniziert [7].

Das Product Backlog ist eine priorisierte Liste dessen, was benötigt wird, um das Produkt weiterzuentwickeln, und wird vom PO erstellt und gepflegt. Das Scrum Team nutzt diese Liste als Arbeitsquelle, wobei der PO die alleinige Verantwortlichkeit trägt, das Backlog unmissverständlich zu kommunizieren und das Produktziel klar zu definieren [3]. Die einzelnen Einträge dieser Liste werden Product Backlog Items genannt und werden kontinuierlich bearbeitet und verfeinert. Dies beinhaltet das Aufteilen von Items in kleinere, konkretere Einheiten, welche der PO anschließend priorisiert [3].

Üblicherweise wird für die Formulierung folgendes Format der User Stories genutzt: „Als [Rolle] möchte ich [Ziel], um [Nutzen]“ [8]. Basierend auf dieser Priorisierung und dem Verfeinerungsprozess wird anschließend im Sprint Planning Event die Anzahl an Items ausgewählt, die das Team innerhalb eines Sprints bearbeiten kann. Abschließend ist zu erwähnen, dass der Product Backlog keine starre Instanz, sondern eine dynamische Liste ist, die stetige Weiterentwicklung erlebt [3].

Typische Herausforderungen des Product Owners

Im Folgenden werden typische Probleme im Bereich Produktvision und Markt- und Nutzeranalyse betrachtet. Zum einen ist ein häufiges Problem eine unklare oder mangelnde Produktvision oder das Vernachlässigen der Produktvision aufgrund von anderen Aufgabenfeldern des PO [9]. Hinzu kommt das Jonglieren der Anforderungen von Kunden und Stakeholdern, welche verstärkt werden können durch die Unfähigkeit, Nein zu sagen, was zu einer Überlastung des Backlogs führen kann [9].

Des Weiteren kann es bei der Markt- und Nutzeranalyse zu einer Informationsüberflutung kommen. Weitere Probleme können fehlende oder veraltete Marktdaten, die nicht identifizierten relevanten Markt- oder Trendinformationen oder das nicht rechtzeitige Erkennen langfristiger Trends sein [10].

Auch in der Rolle des Interessensvertreters muss sich der Product Owner diverser Herausforderungen stellen. Dazu gehört zum einen die asynchrone Kommunikation, die entsteht, wenn es den Stakeholdern nicht möglich ist, an Meetings oder Sprint Events teilzunehmen. Unter klassischer asynchroner Kommunikation versteht man den normalen E-Mail-Kontakt [11].

Es ist zudem wichtig für den PO, die technischen Aspekte des Entwicklerteams zu verstehen und klar und verständlich an die Stakeholder zu kommunizieren, damit es nicht zu Missverständnissen kommt [12].

Der Aufgabenbereich rund um das Product Backlog birgt folgende Herausforderungen: Um User Stories zu generieren, muss der PO eine Menge an unstrukturierten Informationen aus allen Kommunikationskanälen analysieren und daraus relevante Anforderungen extrahieren. Dabei tritt schnell das Problem des Informationsüberflusses auf [13]. Zusätzlich erschweren Missverständnisse zwischen der Fachsprache der Kunden und den technischen Anforderungen der Entwickler diesen Prozess [14].

Eine weitere Herausforderung stellt die kontinuierliche Priorisierung der User Stories dar [15]. Dabei sieht sich der PO häufig mit dem Stakeholder-Dilemma konfrontiert, bei dem die Interessen verschiedener Abteilungen abgewogen und moderiert werden müssen. Diese ergebnisverantwortliche Rolle für das Pflegen des Backlogs erzeugt einen erheblichen Entscheidungsdruck, welcher durch folgendes Konzept zusätzlich verschärft wird: Der Cost of Delay besagt, dass Fehlentscheidungen in der Priorisierung zu messbaren ökonomischen Verlusten des Unternehmens führen können [15].

Zuletzt führt die Vernachlässigung der kontinuierlichen Pflege des dynamischen Backlogs schnell zu veralteten Anforderungen und Ineffizienz [16].

Im Folgenden soll untersucht werden, inwiefern KI bei diesen Herausforderungen unterstützen kann.

Methodik

Die Beantwortung der Forschungsfrage erfolgt mittels einer Evaluation von KI-gestützten Tools und Szenarien, die anhand folgender Bewertungskriterien analysiert werden: Effizienz, Qualität, Kosten, Usability und Integration. Sofern es das jeweilige Szenario zulässt, wird ein Vergleich zwischen der manuellen Bearbeitung der Aufgaben und der automatisierten Durchführung mithilfe von KI-Tools vorgenommen.

A. KI-gestützte Entwicklung der Produktvision

In dem ersten Szenario wird für die Produktvision ein Product Vision Board erstellt. Hierbei handelt es sich um ein gängiges Tool zur Visualisierung der Produktvision [17]. Als KI-Tool wird DesignAI von Venngage verwendet [18]. Dem Tool wird ein Prompt mit den Inhalten für das Product Vision Board gegeben, woraufhin es automatisch ein entsprechendes visuelles Product Vision Board erstellt.

Zur Vorbereitung haben wir einen entsprechenden Prompt formuliert und in das Tool eingegeben. Der Prompt lautet wie folgt:
Erstelle ein Product Vision Board für eine gamifizierte Uni-Lernplattform. Die Plattform soll Kurse, Quizze und ein Level-Up-System enthalten. Fülle die folgenden Bereiche aus:

1. Vision: Langfristiges Ziel und Wirkung der Plattform.
2. Target Group / Nutzer: Wer profitiert von der Plattform? (z.B. Studierende, Dozenten)
3. Bedürfnisse: Welche Probleme oder Herausforderungen sollen gelöst werden?
4. Product: Welche Funktionen gibt es? (Kurse, Quizze, Level-Up, Gamification-Elemente)
5. Business Goals / Nutzen: Welchen Mehrwert bietet die Plattform für die Hochschule, Dozenten und Studierende?
6. Metrics / Erfolgskriterien: Wie wird der Erfolg der Plattform gemessen? (z.B. Engagement, Fortschritt, Nutzerzufriedenheit)

B. KI-gestützte Nutzeranalyse

Das zweite Szenario fällt in den Aufgabenbereich der Nutzeranalyse. Die Wahl des zu untersuchenden Tools fiel auf Amplitude [19], da dieses in Teilen kostenlos zugänglich ist und die finanziellen Mittel nicht für die Bezahlung eines Anbieters zur Verfügung stehen.

In dem zu untersuchenden Szenario wird Nutzer-Feedback verarbeitet und ausgewertet. Amplitude ist ein Produktanalyse-Tool, mit dem automatisierte Nutzeranalysen betrieben werden können. Für dieses Szenario wird das Feature „AI-Feedback“ von Amplitude genutzt, welches Feedback automatisch in die folgenden Kategorien einteilt: Feature Request, Complaint, Bug, Loved Feature, Feature Mention und Takeaway [19].

Zur Vorbereitung haben wir eine CSV-Datei mit künstlichem Nutzerfeedback mit 20 Feedback-Einträgen erstellt und diese im Vorhinein in die Kategorien eingeteilt, um die Qualität der automatisch erstellten Kategorien überprüfen zu können.

C. KI-gestütztes Product Backlog Management

Das dritte Szenario fällt in den Aufgabenbereich der Erstellung, Priorisierung und Pflege des Product Backlogs. Das zu untersuchende Tool ist Gemini 2.5 Flash, da es eine schnelle Verarbeitung der Prompts bietet und multimediale Eingaben zulässt [20].

In dem Szenario haben wir zunächst ein Meeting simuliert, welches die Informationsgrundlage für das Erstellen von User Stories liefert. Es behandelt die Entwicklung eines Notification-Systems im Kontext einer Lernanwendung und enthält zudem die Information, dass Notifications per Mail an die User versendet werden sollen sowie die Möglichkeit der User, Notifications filtern zu können.

Mittels eines KI-generierten Transkripts (Simulation eines Transkriptionstools wie Whisper AI) wurde das Modell mit folgendem Prompt beauftragt:

Du bist Product Owner für ein Softwareprojekt. Anbei erhältst du das Transkript eines Meetings, aus welchem du die angesprochenen Aufgaben als klare User Stories definierst. Nutze dabei die Form: Als [Rolle] möchte ich [Ziel], um [Nutzen]. Arbeite die Akzeptanzkriterien genau aus. Nutze eine Struktur mit Epics. Generiere zusätzlich eine Textdatei.

Für die anschließende Priorisierung der User Stories wurde das gängige MoSCoW-Verfahren (Must, Should, Could, Won’t) genutzt [21]. Dafür wurde unmittelbar nach dem Generieren der User Stories im gleichen KI-Chat folgender Prompt genutzt:

Priorisiere deine entwickelten User Stories mittels dem MoSCoW-Verfahren und exportiere diese im JSON-Format, um die User Stories automatisch als Tasks in Jira anlegen zu können.

Somit wurde der aufgebaute Kontext eines Product Owners durch den vorherigen Prompt genutzt. Das JSON-Format dient dem zeitsparenden, automatischen Anlegen von User Stories in Ticketsystemen wie Jira.

Abschließend wurde das Pflegen des Backlogs mittels KI getestet. Dafür wurde ein weiteres Meeting-Transkript simuliert, welches folgende Änderung an den User Stories enthielt:

Die Nutzer sollen nicht alle E-Mail-Benachrichtigungen deaktivieren können, da sie kritische Meldungen empfangen müssen.

Dafür wurde folgender Prompt genutzt:

Du bist Product Owner für ein Softwareprojekt. Anbei erhältst du das Transkript eines Meetings, das Änderungen an User Stories beinhaltet. Ebenfalls erhältst du die Textdatei mit allen User Stories. Analysiere das Transkript und bestimme, welche User Story geändert werden muss. Generiere eine neue Textdatei mit allen aktuellen User Stories und eine weitere Textdatei im JSON-Format für die geänderte User Story und alle neuen User Stories, nutze die gleiche Struktur.

Dieser Prompt beinhaltet eine Rollenzuweisung, um ihn unabhängig nutzen zu können, da er als Kontext die vorherig generierte Textdatei mit allen User Stories beinhaltet. Ebenso wurde für die Datenpersistenz eine neue Textdatei mit allen aktuellen User Stories erstellt und eine weitere JSON-Format-Datei für geänderte und neue User Stories.

Beim Prompting für die Erstellung und die Pflege der User Stories wurde die Methode des Persona-Pattern angewendet, sowie ein Beispiel im Erstellungs-Prompt mitgegeben. Beide Punkte sind nach [22] entscheidende Faktoren für gutes Prompting und führen zu präziseren Ergebnissen.

D. KI-gestütztes Sprint Review

Das vierte Szenario beschäftigt sich mit dem Thema asynchrone Kommunikation im Sprint Review. Dabei sollte erreicht werden, dass die Stakeholder auch asynchron Rückmeldungen zum Produkt abgeben können, ohne dass sie zwingend am Sprint Review teilnehmen müssen.

Das verwendete Tool für diese Aufgabe war MiroAI, da dieses auch schon vor der Ergänzung der KI-Funktionen ein Tool zur kollaborativen Arbeit war und somit nicht vollständig neu etabliert werden muss [23]. Dazu haben wir ein gemeinsames Board für das Team, die Stakeholder und den Product Owner angelegt, das von jedem auf seine Weise genutzt werden kann.

Das Team nutzt das Board zum Hochladen der Review-Meeting-Folien und die Stakeholder können ihr Feedback dazu abgeben. Der Product Owner hat dann die Möglichkeit, das Feedback zu sammeln, zu kategorisieren und daraus neue Aufgaben für das Entwicklerteam zu definieren.

Da MiroAI eine Anbindung an das Ticketsystem Jira von Atlassian anbietet, können die neuen Aufgaben direkt mit den entsprechenden Tickets verbunden werden und bestehende Tickets in den Review-Meeting-Folien eingefügt werden [23].

Damit die genannten Aufgaben effizienter gelöst werden können, kommen die KI-Funktionen von Miro AI zum Einsatz, die in dieser Fallstudie im oben genannten Kontext getestet werden. Die Stakeholder haben die Möglichkeit, nur einzelne Stichworte als Feedback zu geben, die anschließend durch die KI umformuliert und in den passenden Tonfall angepasst werden. Eine weitere Funktion, die alle Teilnehmenden des Boards nutzen können, ist die Übersetzungsfunktion, die ebenfalls KI-basiert arbeitet.

Der Product Owner kann bei der Bearbeitung des Feedbacks dieses in automatisch generierte Kategorien einteilen, um zum einen ein Stimmungsbild abzubilden oder das Feedback in logische thematische Kategorien zu unterteilen. Eine weitere Funktion ist der KI-Kollege, der die Rolle des Product Leads übernehmen kann und somit aus dem gegebenen Feedback der Stakeholder direkt weitere Aufgaben generiert.

E. KI-gestütztes Release Notes

Das fünfte Szenario beschäftigt sich mit der Automatisierung von Release Notes. Dafür wurden die Gemini Gems genutzt. Diese sind benutzerdefinierte KI-Modelle, die die Möglichkeit bieten, individuelle Anforderungen an die KI weiterzugeben [20].

Das Ziel war es, ein Gemini Gem einzurichten, das aus den Review-Meeting-Transkripten die Release Notes automatisch nach den für Scrum geltenden Anforderungen definiert. Dies haben wir in den benutzerdefinierten Anweisungen festgelegt und eigene Dateien hochgeladen, die als Kontext dienten. Getestet wurde das Gemini Gem anschließend mit einem ebenfalls KI-generierten Meeting-Transkript.

Ergebnisse

Im Folgenden werden die Ergebnisse der Fallstudie dokumentiert.

A. KI-gestützte Entwicklung der Produktvision

Effizienz: Die Generierung des Product Vision Boards erfolgt innerhalb weniger Sekunden. Die Dauer der erforderlichen Nacharbeit ist abhängig von der Ausführlichkeit des eingegebenen Prompts.

Qualität: Das Product Vision Board ist in die folgenden Kategorien unterteilt: Zielgruppe, Bedürfnisse, Produkte und Funktionen sowie Ziele und Metriken. Mit Ausnahme der Business Goals, die lediglich in einem Stichpunkt erwähnt wurden, wurden alle im Prompt gewünschten Bereiche abgedeckt und sinnvolle Unterpunkte zu den jeweiligen Kategorien generiert. Die Unterpunkte sind kurz gehalten; pro Kategorie gibt es drei Unterpunkte. Die Visualisierung des Boards wird als ansprechend empfunden. Es gibt einen Disclaimer: „DesignAI kann Fehler machen oder falsche Ergebnisse generieren.“ Dies legt nahe, dass die generierten Daten nicht immer technisch korrekt sind und eine Überprüfung der generierten Ergebnisse erforderlich ist. Eine Nachbearbeitung des Boards ist möglich. Hierfür bietet das Tool weitere KI-Features, wie die Generierung von Bildern und Symbolen.

Kosten: Es gibt vier Modelle: das kostenlose Modell, das Premium-Modell für 10 Dollar pro Monat, das Business-Modell für 24 Dollar pro Monat und Nutzer, und schließlich das Enterprise-Modell für 499 Dollar pro Monat für mehrere Nutzer [24].

Usability: Die Anwendung ist sehr einfach und intuitiv.

Integration: In der von uns genutzten kostenlosen Version ist keine Integration in andere Tools möglich und das Vision Board kann nicht als Bilddatei heruntergeladen werden. Es besteht jedoch die Möglichkeit, Mitglieder einzuladen und somit kollaborativ an dem Board zu arbeiten.

B. KI-gestützte Nutzeranalyse

Das Nutzerfeedback wird automatisch in die zuvor genannten Kategorien kategorisiert. Zudem wird die Frequenz, mit der Feedback erwähnt wird, erfasst. Eine Filterung nach Datum ist möglich.

Effizienz: Die Generierung der Daten hat ca. 6,30 Minuten gedauert. Dabei muss der Nutzer lediglich zu Beginn die Daten hochladen. Die Nachprüfung, bei der das schriftliche Feedback mit dem generierten Titel und der Kategorie abgeglichen wurde, dauerte ca. zehn Minuten. Die ermittelten Zeit- und Kostenwerte werden in der Tabelle „Fig. ??” dargestellt. In der Spalte „Manuell“ erfolgte die manuelle Zuordnung der Feedback-Beiträge zu einer Kategorie sowie die Ermittlung der Häufigkeit der Erwähnung eines Features.

TABLE I – Vergleich: Manuelle und KI-gestützte Nutzeranalyse

Qualität: Von den 20 Feedback-Einträgen zeigen 17 eine Übereinstimmung der durch KI generierten Kategorien mit den von uns manuell bestimmten Kategorien. Es kam jedoch mehrfach vor, dass Feedback mehreren Kategorien gleichzeitig zugeordnet wurde. Drei von uns speziell angelegte Bug-Feedbacks wurden nicht als Bug, sondern als Complaint erkannt. In unserer Probe unterscheidet das Tool außerdem nicht zwischen Feedback zu einem neuen Feature und Feedback zur Verbesserung eines bestehenden Features.

Usability: Das Finden und Benutzen bzw. Einarbeiten der einzelnen Features war intuitiv und schnell. Da das Tool Amplitude jedoch zahlreiche weitere Funktionen, beispielsweise Monitoring, bietet, können wir uns vorstellen, dass die vollständige Einarbeitung etwas Zeit in Anspruch nimmt.

Integration: Als Quelle kann entweder eine CSV-/Docs-Datei hochgeladen oder die Daten über eines von 13 weiteren Tools integriert werden. Weitere Integrationen können angefragt werden.

C. KI-gestütztes Product Backlog Management

Das KI-Modell Gemini 2.5 Flash konnte aus dem Meeting-Transkript erfolgreich Epics, User Stories und zugehörige Akzeptanzkriterien generieren, priorisieren und Änderungen vornehmen. Tabelle II visualisiert einen Auszug des KI-generierten Product Backlogs.

Effizienz: Die KI ermöglichte eine schnelle Erstellung einer ersten groben Version des Backlogs und erleichterte den Einstieg in die Formulierung der Stories erheblich. Die Stärke der KI liegt in der schnellen Verarbeitung großer Datenmengen, was dem Problem des Informationsüberflusses entgegenwirkt. Auch die Änderungen an bestehenden Stories anhand neuer Transkripte verlief zeiteffizient. Jedoch erforderte vor allem die KI-generierte Priorisierung manuellen Mehraufwand. Hier wirkte der Einsatz von KI durch fehlerhafte Abhängigkeiten kontraproduktiv und erforderte eine zeitintensive Korrektur.

Qualität: Die funktionale Qualität der Ergebnisse ist gemischt. Positiv hervorzuheben ist die logische Strukturierung in Epics und die fachliche Nachvollziehbarkeit der Stories. Ebenso sind diese weitestgehend unabhängig voneinander und klein genug. Auch kritische Compliance-Themen (z. B. DSGVO) wurden von der KI in den Akzeptanzkriterien berücksichtigt.

Negativ fielen Anti-Patterns auf: Teilweise wurde, wie in US 1.1, ein technisches System (z. B. „Backend-System“) als Rolle der User Story definiert, anstatt einer menschlichen Nutzerrolle. Zudem waren einige Akzeptanzkriterien nicht mess- oder testbar formuliert (z. B. fehlende Lastvorgaben für „hohes Volumen“). Bei der Priorisierung zeigte die KI deutliche Schwächen: Sie folgte fälschlicherweise einem Sichtbarkeits-Prinzip (Frontend vor Backend-Infrastruktur) anstatt Entwicklungsabhängigkeiten zu respektieren. Dies würde in der Praxis zu technischem und finanziellem Mehraufwand führen. Die Analyse der Priorisierung (siehe Tab. III) zeigt, dass die KI sichtbare Features fälschlicherweise vor der notwendigen technischen Basis einordnet. Dies führt zu folgenden Blockaden in der Entwicklung:

Mit der grundlegenden Kategorisierung der E-Mails (US 2.1) erst an vorletzter Stelle fehlt den Entwicklern in US 1.1, die Logik für das Tagging der E-Mails. Ebenso wird bei US 2.2 die UI vor der Datenstruktur in US 2.1 implementiert. Somit muss das Team mit Platzhaltern arbeiten und auf die Fertigstellung von US 2.1 warten. Anschließend ist ein zeitintensives Refactoring des Frontends notwendig.

Zudem missachtet der Vorschlag rechtliche Abhängigkeiten. Die Priorisierung des E-Mail-Versands (US 1.1) vor der damit verbundenen technischen Basis kann sowohl zu funktionalen Problemen als auch zu Compliance-Risiken führen.

TABLE III – Vergleich Priorisierung: KI-Vorschlag vs. manueller Lösungsvorschlag

Die Abmelde-Funktion (US 1.3) führt zu einem Produkt-Release, bei dem den Nutzern keine Möglichkeit geboten wird, sich von den Benachrichtigungen abzumelden. Dies gefährdet nicht nur die Nutzerzufriedenheit, sondern kann auch zu rechtlichen Abmahnungen führen.

Das Pflegen der User Stories bei geänderten Anforderungen verlief hingegen qualitativ hochwertig und detailliert. Die Änderung beschränkt sich dabei nicht nur auf eine einzelne User Story, sondern die KI hat in diesem Fall das Zusammenspiel mehrerer User Stories erfasst und die Änderung vollständig integriert.

Usability / Integration: Die Bedienung des Chat-Interfaces des Gemini KI-Modells ist intuitiv. Die multimediale Eingabe erlaubte verschiedene Dokumente einzubinden.

D. KI-gestütztes Sprint Review

Effizienz: Die KI-Funktionen konnten ohne größeren Aufwand angewendet werden und waren leicht zu finden. Die Funktionen mussten nicht zusätzlich aktiviert werden, sondern standen dem Nutzer unter den weiteren standardmäßigen Einstellungen zur Verfügung.

Qualität: Die Qualitäten der Funktionen „Umschreiben“, „Tonfall anpassen“ und „Übersetzen“ waren sehr gut und es konnten keine Mängel festgestellt werden. Die Funktion zur automatischen Kategorisierung der Feedback-Notizen erstellte sinngemäße Kategorien, fügte jedoch nicht mehrere Notizen einer Kategorie zu. Die Aufgaben, die der KI-Kollege aus den Feedback-Notizen generierte, wirkten stark generisch und wenig individuell angepasst.

Usability: Die Benutzung der KI-Funktionen war intuitiv und schnell. Es benötigte keine spezielle Anleitung und war sehr selbsterklärend. Da es jedoch noch weitere individuelle Einstellungen gibt, wie z. B. das Anpassen des KI-Modells, können diese Funktionen den Einarbeitungsaufwand erhöhen. Für die getesteten Funktionen benötigte es jedoch kein spezifisches Wissen.

Integration: Da eine Anbindung an das Ticketsystem Jira möglich ist, kann man auf einfache Weise eine direkte Verbindung zu einem bestehenden System herstellen und somit Inhalte importieren.

E. KI-gestützte Release Notes

Effizienz: Das Einrichten des Gemini Gems war leicht verständlich und konnte gut umgesetzt werden. Zu erwähnen ist, dass es sich um ein zusätzliches Tool handelt und die Zeit der Einrichtung mit eingeplant werden muss.

Qualität: Die Antwortqualität des Gemini Gems auf das hochgeladene Transkript war gut. Das Gemini Gem lieferte eine Release Note, die die Punkte aus dem Skript beinhaltete. Negativ anzumerken ist die Form der Release Note, da diese nicht tabellarisch war und somit erst formatiert werden musste, bevor sie verwendet werden kann. Außerdem erhält man je nach eingegebenem Prompt unterschiedliche Ergebnisse, was zu einer veränderten Qualität führen kann. Neben der Qualität ist auch die Länge der Ausgabe relevant, da diese nicht immer einheitlich ist und beobachtet werden konnte, dass nicht ausschließlich die Release Note ausgegeben wurde, sondern meist zusätzlicher Inhalt ebenfalls Teil der Ausgabe war.

Usability: Insgesamt war die Handhabe und das Einrichten des Gemini Gems sehr schnell und intuitiv. Es bedarf keinem zusätzlichen Wissen und alle Schritte waren selbsterklärend. Da die Kommunikation mit dem Gemini Gem über das gleiche Chatformat abläuft, wie auch die Kommunikation mit Gemini, kam es zu keinen Schwierigkeiten in der Bedienung.

DISKUSSION

A. KI-gestützte Entwicklung der Produktvision

Das Tool kann bei der Erstellung eines Product Vision Boards unterstützen, da die Generierung von Ideen und deren Visualisierung sehr schnell erfolgt. Allerdings muss das Board anschließend überprüft werden, da Fehler auftreten können. Da die Unterpunkte kurz gehalten sind, ist das Tool für eine erste Ideenfindung gut geeignet. Wenn ein detailliertes Board gewünscht ist, sollte es jedoch nachbearbeitet werden. Ein Nachteil besteht darin, dass das Herunterladen des Boards nicht möglich ist.

In Bezug auf die genannten Herausforderungen des Product Owners hilft das Tool insbesondere dabei, dass die Produktvision nicht vernachlässigt wird. Durch die schnelle Generierung und die Visualisierung – beispielsweise durch automatisch erstellte Bilder – kann zudem sichergestellt werden, dass die Produktvision verständlich und klar vermittelt wird.

B. KI-gestützte Nutzeranalyse

Insgesamt wurden die Feedback-Einträge sinnvoll kategorisiert, und andere Features, wie das Sortieren nach Datum, haben zuverlässig funktioniert. Es könnte jedoch für den Nutzer verwirrend sein, dass ein Feedback-Eintrag mehreren Kategorien zugeordnet ist und doppelt vorkommt. Dies kann zu längerer Nacharbeit führen und die weitere Datenauswertung weniger effizient machen.

Die Kategorisierung gibt jedoch einen Überblick darüber, welche Features viel Feedback erhalten, auch positives. Aus diesen Informationen kann geschlossen werden, wie häufig diese Features genutzt werden. Zur weiteren Analyse scheinen sich die kategorisierten Daten daher gut anzubieten. Außerdem ist eine breite Integration von Tools möglich, wodurch sich das System an bestehende Systeme anschließen lässt.

Im Vergleich zur manuellen Nutzeranalyse wurde durch die automatische Generierung eine Zeitersparnis von sieben Minuten erzielt. Wir gehen davon aus, dass sich diese Zeitersparnis bei sehr großen Datenmengen noch deutlicher bemerkbar macht.

Das Problem der Informationsüberflutung bei der Nutzeranalyse kann durch den Einsatz von KI deutlich reduziert werden, indem Daten automatisiert analysiert und kategorisiert werden. Dadurch muss der PO weniger Zeit für die manuelle Auswertung aufwenden und kann die gewonnene Zeit für andere Aufgaben einsetzen. Allerdings zeigt sich in unserem Beispiel, dass die Datenqualität nicht immer optimal ist. Es kommt etwa zu mehrfachen oder fehlerhaften Kategorisierungen, weshalb eine manuelle Nachbearbeitung weiterhin notwendig bleibt.

Ein weiteres Bedenken betrifft den Datenschutz und die anonymisierte Verarbeitung der Nutzerdaten durch Amplitude. Darüber hinaus muss geprüft werden, ob die Zeitersparnis ausreicht, um die Kosten des KI-Tools zu rechtfertigen.

C. KI-gestütztes Product Backlog Management

Die Fallstudie zeigt, dass KI-Modelle wie Gemini 2.5 Flash einen soliden Ansatz für das Product Backlog schaffen können, die Ergebnisse jedoch nicht direkt für einen Sprint einsatzbereit sind. Der PO profitiert von dieser Grundlage, muss sich jedoch der Fehleranfälligkeit von KI-Modellen bewusst sein und aktiv Zeit in die manuelle Kontrolle investieren. Andernfalls besteht die Gefahr, aus Bequemlichkeit ein übermäßiges Vertrauen gegenüber der KI zu entwickeln.

Besonders deutlich wurden die Grenzen der KI bei der Priorisierung. Das Stakeholder-Dilemma und die technischen Abhängigkeiten konnten von der KI nicht vollständig erfasst werden. Grund dafür kann das fehlende Kontextwissen über das Projekt und die Stakeholder sein. Dementsprechend bleibt die menschliche Expertise unverzichtbar, um einen reibungslosen Entwicklungsfluss zu gewährleisten und rechtliche sowie wirtschaftliche Risiken zu minimieren.

In der kontinuierlichen Pflege und Aktualisierung des Backlogs zeigte das Tool hingegen großes Potenzial, den PO zeittechnisch zu entlasten.

D. KI-gestütztes Sprint Review

Insgesamt können die KI-Funktionen von MiroAI sinnvoll eingesetzt werden und zeigten sich in der Fallstudie als nützlich. Die Funktionsweise der automatischen Kategorien der Feedbacknotizen könnte in einem größeren Rahmen zu einer hohen Anzahl an Kategorien führen, die statt Übersicht zu schaffen, zusätzlichen Aufwand erzeugen könnten. Grund dafür ist, dass die Kategorien sehr spezifisch gewählt wurden, wodurch es schwierig ist, weitere Feedbacknotizen in bestehende Kategorien einzuordnen.

Des Weiteren zeigte sich in unserem Use Case, dass die generierten Aufgaben aus den Feedbacknotizen nicht immer vollständig umsetzbar sind und eine Nachbearbeitung erfordern. Die Aufgaben können in diesem Fall eher als Orientierung genutzt werden und hängen stark vom Inhalt und der Qualität des Feedbacks ab. Somit kann es zu besseren oder schlechteren Ergebnissen bei der Generierung der Aufgaben kommen.

E. KI-gestützte Release Notes

Die Funktionen des Gemini Gems konnten in dem Use Case „KI-gestützte Release Notes“ gut angewendet werden und waren erfolgreich. Insgesamt zeigte das Ergebnis, dass es leicht ist, ein individuelles Gemini Gem einzurichten, jedoch ist dies abhängig von der Genauigkeit der benutzerdefinierten Anweisungen.

Zusätzlich ist zu beachten, dass die Gefahr von Halluzinationen einer KI immer besteht, weshalb es wichtig ist, die Ausgabe nachträglich vor der Veröffentlichung zu prüfen. Je nach Länge der Ausgabe kann dies einen hohen zeitlichen Aufwand bedeuten, da der generierte Inhalt häufig nicht sehr kurz ist. Somit muss abgewogen werden, wie sehr sich dieses Tool in dem genannten Use Case eignet.

F. Allgemein

Zudem gibt es Herausforderungen im Aufgabenbereich des PO, die auf menschlicher Ebene liegen – beispielsweise das Setzen von Prioritäten oder das bewusste Nein-Sagen gegenüber Stakeholdern. Solche sozialen und kommunikativen Aspekte können durch KI nicht vollständig gelöst werden.

Außerdem dürfen bei der Unterstützung durch KI-Tools die Kosten, die zur Nutzung entstehen, nicht vernachlässigt werden. Die untenstehende Tabelle beinhaltet die Kosten, die ungefähr pro Mitarbeitendem durch den Einsatz von KI-Tools entstehen. Die Summe von 90 Euro pro Mitarbeitendem wirkt auf den ersten Blick überschaubar, jedoch summiert sich dieser Wert schnell je nach Größe des Teams. Damit kann es zu hohen Investitionssummen kommen, die für kleinere Unternehmen oder Start-ups schwieriger zu bewältigen sind.

Neben den sozialen und finanziellen Aspekten lassen sich folgende technische Grenzen erkennen: Die KI-Modelle leiden an einer Kontextarmut. Sie verfügen nur über den kleinen Kontext, welcher ihnen über Prompts zur Verfügung gestellt wird. Somit besitzen die Modelle keinen kompletten Überblick über die Projekte, historische Projektentscheidungen, Stakeholder-Informationen oder firmeninternes Wissen. Da unter anderem die Priorisierung im Backlog oft von solchen komplexen Faktoren abhängt, kann die KI nur eine schwache, chatlokale Priorisierung vermuten und keine globale Priorisierung empfehlen.

Eine mögliche technische Lösung könnte hier die Implementierung von RAG-Systemen bieten, die der KI Zugriff auf die gesamte Projektdokumentation, internes Firmenwissen und historische Firmendaten gewähren.

Ein weiteres Risiko liegt in der Konsistenz und Nachvollziehbarkeit der Ergebnisse. Das mehrmalige Ausführen desselben Prompts mit identischen Transkripten führte oft zu unterschiedlichen Ergebnissen. Diese Abweichungen erschweren eine einheitliche Arbeitsstruktur für Product Owner sowie die verlässliche Begründung von Entscheidungen gegenüber Stakeholdern, da keine klare Nachvollziehbarkeit vorhanden ist.

Besonders kritisch ist die Abkopplung des Menschlichen. Deutlich wird dies beispielsweise im Bereich der KI-gestützten Analyse von Transkripten, die zuvor von KI-gestützten Transkriptionstools (z. B. Whisper AI) erstellt wurden. Ein Textprotokoll beinhaltet nicht die Menge an Informationen, die ein multimodales Gespräch enthält. Nonverbale Signale wie Gesichtsausdruck, Zögern oder Betonung sind oft Indikatoren dafür, was ein Stakeholder wirklich meint. Diese gehen in Transkripten verloren und tragen zur Kontextarmut der KI bei.

Zudem besteht die Gefahr, dass sich Fehler unbemerkt fortpflanzen. Werden beispielsweise wichtige Wörter in einem Meeting falsch transkribiert, zieht sich dieser Fehler durch den gesamten KI-Workflow bis in die fertige User Story. Dies unterstreicht die Notwendigkeit des Prinzips des „Human-in-the-Loop“. Somit ist von einem vollständigen Vertrauen des Product Owners in die KI-generierten Inhalte abzuraten. Stattdessen sollten die Ergebnisse stets durch eine menschliche Instanz validiert werden.

In Bezug auf Limitationen muss erwähnt werden, dass es sehr viele Tools auf dem Markt gibt und nur ein kleiner Teil davon in dieser Studie abgedeckt werden kann. Außerdem bieten die ausgewählten Tools selbst sehr viele Funktionen, die ebenfalls nur stichprobenartig getestet wurden. Eine weitere Limitation ist die Datenmenge, die zu Testzwecken in den unterschiedlichen Tools verwendet wurde. Diese kann das Ergebnis verändern und je nach Komplexität ein Tool besser oder schlechter nutzbar machen. Daher kann diese Studie nur einen ersten Eindruck vermitteln.

Risiken und die Zukunft der Rolle des PO

Da die durchgeführte Fallstudie zeigt, dass die Rolle des PO mit den KI Tools definitiv im Wandel ist, bringt dies auch viele Veränderungen in den Arbeitsalltag des PO. Zu diesen Änderungen gehören besonders auch die ethischen Aspekte, die nicht vernachlässigt werden dürfen. Dazu gehört, dass KI-generierte Inhalte auch als solche gekennzeichnet sind. Außerdem muss der Datenschutz eingehalten werden und es dürfen keine personenbezogenen Daten der KI zugeführt werden. Ein weiterer Punkt ist, wie auch schon in den Ergebnissen der Fallstudie erwähnt, das Kontrollieren der KI-generierten Inhalte, um Fehler zu vermeiden [29]. Es kann zudem zu einer Verzerrung der Realität kommen, da die KI-Modelle auf historischen Daten basieren und somit Minderheiten unterdrückt werden können, da diese in den Datensätzen nicht ausreichend repräsentiert werden [29]. Das könnte z. B. beim Erstellen von User Stories der Fall sein und es ist wichtig, sich dessen bewusst zu sein. KI wird somit zunehmend Teil der täglichen Arbeit und dient als Assistenz, sollte die Rolle des Product Owners jedoch nicht ersetzen [30].

Fazit

Diese Arbeit sollte aufzeigen, in welchem Umfang KI-Tools Aufgaben des Product Owners übernehmen können bzw. bei der Bewältigung typischer Herausforderungen unterstützen können. Dabei stellten wir uns auch die Frage, in welchen Bereichen menschliche Kompetenzen unverzichtbar bleiben. Unsere Fallstudie hat gezeigt, künstliche Intelligenz ermöglicht es dem PO, Teile seiner Aufgaben zu automatisieren und dadurch Zeit zu gewinnen. Besonders viel Zeit konnte durch die Unterstützung bei wiederkehrenden Aufgaben und Abläufen eingespart werden. Weniger effizient war der Einsatz der KI bei Priorisierungsaufgaben und besonders bei Aufgaben, die nur mit einem hohen Maß an Kontextwissen erledigt werden konnten. Außerdem konnte auch festgestellt werden, dass die Zeit der Einarbeitung und auch die Kosten der neuen Tools nicht vernachlässigt werden dürfen. Abschließend kann man sagen, dass die KI den Alltag eines Product Owners bereichern kann, es nur zwingend notwendig ist, die KI ausschließlich als ein Mittel zu sehen und die eigene Arbeit nicht ersetzen kann. Besonders analytische Aufgaben können somit in der Zukunft an Relevanz gewinnen und weniger das stetige Abarbeiten von Routineaufgaben. Unabhängig von der Abhilfe, die KI in den routinemäßigen Abläufen schafft, hat sich auch herausgestellt, dass die analytische Arbeit besonders wichtig ist, da die Datenmengen mit der Nutzung von KI steigen. Je nach Tool bzw. besonders bei dem Einsatz von generativer KI wie z. B. ChatGPT oder das Gemini Gem zeigte sich, dass häufig lange Antworten generiert werden, die schnell dazu verleiten, nur kurz die Zeilen zu überfliegen, statt sie aufmerksam durchzuarbeiten und sich somit auch schneller Fehler einschleichen und auch der zeitliche Rahmen zunimmt. Neben den ganzen positiven Aspekten stellt sich somit trotzdem die Frage, wie zuverlässig die KI Daten verarbeitet und wie hoch die Qualität der erzeugten Ergebnisse ist. Zudem muss geprüft werden, ob sich die Investition in die KI-Tools tatsächlich durch die eingesparte Arbeitszeit rechnet. KI kann den PO also spürbar entlasten, vorausgesetzt, sie liefert technisch korrekte und verlässliche Daten, die kein zeitintensives und manuelles Korrigieren verlangen. Somit kann abschließend die Frage beantwortet werden, dass die Aufgaben des Product Owners nicht vollständig von der KI ersetzt werden können, sondern ausschließlich eine Entlastung, bei richtiger Einarbeitung und Bedienung, darstellen.

Ausblick

In weiteren Studien könnte untersucht werden, welchen Einfluss ein RAG-Systems in Kombination mit KI Tools mit sich bringen würde, um der Kontextarmut der KI über das Unternehmen und die Projekte entgegenzuwirken. Ebenso könnte untersucht werden, inwieweit sich Aufgaben, beispielsweise in der Marktanalyse, durch den Einsatz von KI-Agenten automatisieren lassen, sodass der PO mehr Zeit für andere Aufgaben hat. Auch eine breiter angelegte Studie mit einem realen Szenario aus der Wirtschaft wäre denkbar. Diese Fallstudie wurde ausschließlich mit beispielhaften Daten durchgeführt und könnte somit mit einer erhöhten Datenmenge und auch um reale Daten ergänzt werden. Somit könnte man klarere Schlüsse ziehen und nicht nur Annahmen treffen.

REFERENCES

[1] Statista. (2024). KI in deutschen Unternehmen. Accessed on 18 February 2026. [Online]. Available: https://de.statista.com/statistik/studie/id/173446/dokument/ki-in-deutschen-unternehmen/

[2] IBM. (2026). AI and Project Management. Accessed on 18 February 2026. [Online]. Available: https://www.ibm.com/think/topics/ai-project-management

[3] Ken Schwaber und Jeff Sutherland. (2020). The Scrum Guide – Deutsch (Version 2020). Accessed on 10 February 2026. [Online]. Available: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf

[4] Atlassian. (2026). Was bedeutet Agile? – Agile Methoden und Projektmanagement. Accessed on 10 February 2026. [Online]. Available: https://www.atlassian.com/de/agile

[5] Ulrike Schwitzko. (2025). Die Aufgaben des Product Owners. Accessed on 10 February 2026. [Online]. Available: https://pm1.de/aufgaben-product-owner/

[6] K. S. Rubin. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley. Accessed on 18 February 2026.

[7] Product Plan. Release Notes. Accessed on 19 February 2026. [Online]. Available: https://www.productplan.com/glossary/release-notes/

[8] D. Ops. User Story Template for Agile | Agile Alliance. [Online]. Available: https://agilealliance.org/glossary/user-story-template/

[9] Sanjay Saini. (2024). Top 5 Pitfalls of New Product Owners and How to Avoid Them. Accessed on 10 February 2026. [Online]. Available: https://www.scrum.org/resources/blog/top-5-pitfalls-new-product-owners-and-how-avoid-them

[10] A. Mohamed. (2024). Market Research Process: Understanding, Steps, and Challenges. Accessed on 18 February 2026. [Online]. Available: https://www.aimtechnologies.co/2024/01/30/market-research-process-understanding-steps-and-challenges/

[11] Julia Martins. (2025). Asynchrone Kommunikation: 10 Tipps im Überblick!. Accessed on 18 February 2026. [Online]. Available: https://asana.com/de/resources/synchronous-vs-asynchronous-communication

[12] P. Mohagheghi et al. (2024). “The Product Owner and Its Impact on Success and Challenges in Agile Scrum Projects.” Procedia Computer Science. Accessed on 18 February 2026.

[13] R. Pichler. Agile Product Management with Scrum: Creating Products that Customers Love. [Online]. Available: https://www.oreilly.com/library/view/agile-product-management/9780321684165/

[14] I. Nonaka. “The Knowledge-Creating Company.” In: The Economic Impact of Knowledge. Routledge.

[15] D. G. Reinertsen. The Principles of Product Development Flow.

[16] J. Highsmith. Agile Project Management: Creating Innovative Products. Pearson Education.

[17] Agile Academy. (2026). Ein Produkt entwickeln, das die Nutzer wollen – mit dem Vision Board von der Idee bis zum Backlog. Zugriff am 19. Februar 2026. [Online]. Available: https://www.agileacademy.com/de/product-owner/ein-produkt-entwickeln-das-die-nutzer-wollen-mit-dem-vision-board-von-der-idee-bis-zum-backlog/

[18] Venngage. (2026). AI Vision Board Generator. Zugriff am 19. Februar 2026. [Online]. Available: https://venngage.com/aitools/vision-board-generator

[19] Amplitude. (2026). Amplitude – Produktanalyse-Plattform. Accessed on 10 February 2026. [Online]. Available: https://amplitude.com/de-de

[20] Gemini. Erstelle benutzerdefinierte KI-Experten – mit Gems. Accessed on 18 February 2026. [Online]. Available: https://gemini.google/at/overview/gems/?hl=de

[21] Agile Business Consortium. DSDM Project Framework Handbook. [Online]. Available: https://www.agilebusiness.org/dsdm-project-framework.html

[22] J. White et al. “A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT.” [Online]. Available: http://arxiv.org/abs/2302.11382

[23] Miro. (2025). Die KI-Plattform für Teamarbeit. Accessed on 18 February 2026. [Online]. Available: https://miro.com/de/ai/ai-overview/

[24] Venngage. (2026). Pricing. Zugriff am 19. Februar 2026. [Online]. Available: https://venngage.com/pricing

[25] Google Cloud. Die passende Version für Ihre Organisation. Accessed on 18 February 2026. [Online]. Available: https://cloud.google.com/gemini-enterprise?hl=de

[26] Miro. Pricing. Accessed on 18 February 2026. [Online]. Available: https://miro.com/pricing/

[27] Notion. One Tool for Your Whole Company. Free for Teams to Try. Accessed on 18 February 2026. [Online]. Available: https://www.notion.com/pricing

[28] Microsoft. Flexible Copilot-Pläne für jede Organisation. Accessed on 18 February 2026. [Online]. Available: https://www.microsoft.com/de-de/microsoft-365/copilot/pricing?market=de

[29] Stephan Wolpers. (2025). Ethische KI für Product Owner und Produktmanager. Accessed on 18 February 2026. [Online]. Available: https://berlinproductpeople.com/de/ethische-ki-product-owner-produktmanager/

[30] Oliver Winter und Tim Klein. (2024). Die Produktwerker: KI als Wingman für Product Owner. Accessed on 18 February 2026. [Online]. Available: https://www.heise.de/blog/Die-Produktwerker-KI-als-Wingman-fuer-Product-Owner-9823734.html