3 Product Owner Jira / Confluence Tipps, durch die Sie leichter mit den Tools arbeiten

Mit dem agilen Produktframework Scrum kam auch die Rolle Product Owner in das Projektmanagement-Geschäft. Dieser Artikel ist Bestandteil unserer Blog-Reihe „Jira für Rollen im Projektmanagement“. Hier finden Sie 3 Tipps für die Rolle als Product Owner im Umgang mit dem Projektmanagement Tool Jira. Das sind die Kapitel, die auf Sie warten:

• Aufgaben eines Product Owners
• Tipp 1: Stories schreiben, die nicht bleiben
• Tipp 2: Akzeptanzkriterien für gute Stories
• Tipp 3: Wenn es mal zu viel wird: Stories aufteilen
• Fazit – der Einsatz von Jira als Product Owner ist leicht, aber…

Doch bevor wir mit den Aufgaben und Tipps für den Product Owner starten ist es sinnvoll, einen Überblick über die verschiedenen Atlassian Tools zu haben. Klären wir also zunächst, worum es sich bei Jira und Confluence handelt.

Was ist Jira?

Atlassian Jira ist ein webbasiertes Tool für Aufgabenmanagement, Projektmanagement und Fehlerverwaltung. Es kommt hauptsächlich bei Teams in der Produkt- und Softwareentwicklung zum Einsatz. Agil arbeitende Teams werden mittels verschiedener Projekt- und Boardtypen unterstützt, z.B. Kanban, Scrum, Projektmanagement .

Was ist Confluence?

Atlassian Confluence ist eine webbasierte Wiki-Software, die die interne Zusammenarbeit in Projektteams und im Unternehmen unterstützt. Das Tool integriert sich gut mit Jira, daher bietet diese Kombination beste Voraussetzungen für agil arbeitende Teams.

Warum spezielle Jira Tipps für Product Owner?

Die Rolle des Product Owner wird mittlerweile in vielen Projekten eingesetzt – auch bei denen, die nicht auf dem Framework Scrum basieren, sondern lediglich Elemente daraus bedienen. Der Aufgabenbereich des Product Owner ist folglich von Unternehmen zu Unternehmen unterschiedlich, da Scrum nicht als einheitliche Grundlage verwendet wird.

Jira wiederum ist eine Aufgabenmanagement-Software, die weltweit bei über 14.000 Kunden von Atlassian im Einsatz ist. Sie hat demnach eine sehr hohe Verbreitung und wird sowohl in klassisch geprägten Konstellationen als auch in modernen Projektmanagement-Organisationen verwendet.

Als Product Owner kommen Sie heute kaum noch um den Einsatz digitaler Tools herum. Da Jira aktuell der Weltmarktführer für Aufgabenmanagement ist, konzentrieren wir uns in diesem Artikel auf die Tipps im Umgang mit Jira.

Aufgaben eines Product Owner

Wie bereits erwähnt, ist es von Organisation zu Organisation unterschiedlich, welche Aufgaben ein Product Owner übernimmt. Folgende Aufgaben fallen jedoch häufig in den Verantwortungsbereich der Rolle:

• Anforderungen aufnehmen und abstimmen
• Repräsentation von Stakeholdern im Team
• Kommunikation nach innen und außen
• Produkt- oder Projekt-Marketing
• Definition der Roadmap
• Beschreibung, WAS umgesetzt werden soll
• Priorisierung und Budgetierung
• Fokus auf der Produktentwicklung und Integration in die Unternehmensstrategie

Die meisten dieser Punkte können mithilfe von Jira umgesetzt werden. Der Schwerpunkt von Jira liegt dabei auf der Formulierung der Anforderungen und der Erstellung der Roadmap.

Schauen Sie sich nun die Liste noch einmal genau an. Fällt Ihnen etwas auf?

Bei den Anforderungen an den Product Owner liegen kaum Unterschiede zur Rolle der Projektleitung vor. Der Fokus liegt hier allerdings mehr auf dem Projekt und dessen erfolgreicher Umsetzung. Anders beim Product Owner: Der Fokus liegt hier darauf, dass das Produkt langfristig erfolgreich ist und dass es zur Gesamtstrategie des Unternehmens passt.

3 Tipps für Product Owner

Anforderungen aufnehmen, das WAS beschreiben, priorisieren und eine Roadmap erstellen. Das sind alles Aufgaben, die Sie als Product Owner in Jira abbilden können. Aber auch wenn Sie es nicht selbst machen, sondern die Aufgabe an das Team delegiert haben, werden Ihnen die nachfolgenden Tipps sicher weiterhelfen.

Tipp 1: Stories schreiben, die nicht bleiben

Stories schreiben in Jira ist sehr einfach. Doch gute Stories zu schreiben, die vom Team verstanden werden und das beinhalten, was die Stakeholder wollen, ist die Herausforderung.

Warum also Stories schreiben, die nicht bleiben?

Eine Story dient nur einem Zweck: der Umsetzung einer Anforderung oder eines Wunsches. Sie ist nicht für die Dokumentation ausgelegt, gleichwohl wird sie in manchen Unternehmen auch zur Dokumentation des Umgesetzten eingesetzt.

Was sind Anforderungen?

Anforderungen sind funktionale und nicht-funktionale Spezifikationen, Wünsche und Ideen. Meistens sind Anforderungen zunächst unklar und entwickeln sich mit der Zeit. Wenn sie spezifisch genug sind, können sie als Story in Jira erfasst werden.

Wo werden Anforderungen ansonsten beschrieben?

Stories können grundsätzlich immer verwendet werden.

Es kann sich aber auch anbieten, Anforderungen zunächst in Confluence zu beschreiben und mit den Stakeholdern abzustimmen. Aus einer Anforderung werden dann eine bis mehrere Stories erstellt. Dafür bietet sich Jira als Tool an. Sie sollten jedoch darauf achten, dass Sie die Stories in Jira mit den Anforderungen in Confluence verlinken.

Was ist der Vorteil des Einsatzes von Confluence?

Wenn Sie die Anforderungen in Confluence beschreiben, haben Sie dort auch die geeignete Stelle zur Dokumentation gefunden. Confluence kann besser zur strukturierten Ablage von Informationen verwendet werden.

Jira ist kurzlebig. Sobald eine Story abgeschlossen ist, verschwindet sie aus dem sichtbaren Bereich und muss gesucht werden, um wieder sichtbar zu werden.

Wie kann das noch strukturiert werden?

Jira arbeitet standardmäßig mit sogenannten Epics. Ein Epic ist eine große Story. Diese wird in Jira als ein Strukturelement dargestellt. Unter einem Epic können dabei mehrere Stories untergebracht werden. Die Struktur der Anforderungen kann wie im folgenden Beispiel aussehen:

Die Struktur gestaltet sich in der Regel so:

1. Aus einer Anforderung in Confluence können eine bis mehrere Epics erstellt werden.
2. Unter einem Epic kann es Story, Bug und Task geben.
3. Stories und Tasks können dabei wiederum in Sub-Tasks unterteilt werden.

Wofür werden Stories verwendet?

Stories werden für die Beschreibung von Kundennutzen verwendet. In den letzten Jahren hat sich dafür ein Template zur Beschreibung von User Stories etabliert:

Als [Nutzer] möchte ich [Funktion], um [Mehrwert].

Ein Beispiel: Als Autor des Blogbeitrags möchte ich das Schreiben von Stories vermitteln, um Product Owner in ihrer täglichen Arbeit zu unterstützen.

Wie werden Stories in Jira dargestellt?

Drei Felder sind in Jira Pflichtfelder: Projekt, Vorgangstyp und Beschreibung.

Das oben genannte Template wird in der Beschreibung eingetragen. Für unser Beispiel bedeutet das:

Nur der einleitende Text wird allerdings nicht ausreichen, um die Story umzusetzen. Im Fall des Blog-Beitrags werden noch benötigt:

• Keywords des Beitrags
• Länge des Beitrags
• Beitragsbilder
• Welche Tipps behandelt werden sollen

Sie müssen als Product Owner also noch weitere Informationen liefern, um die Story zu beschreiben. Dazu können Sie einfach weitere Informationen in der Beschreibung ergänzen oder auch als Anhang hinzufügen.

Eine Möglichkeit, um weitere Informationen zu erfassen, ist in Form der Akzeptanzkriterien.

Tipp 2: Akzeptanzkriterien für gute Stories

Das zuvor beschriebene Beispiel wurde um die Akzeptanzkriterien ergänzt:

In dem Beispiel wurden zur Story drei Akzeptanzkriterien in der Beschreibung aufgenommen:

• Stories schreiben, Akzeptanzkriterien und Stories aufteilen wurden beschrieben
• Beitragslänge von ca. 1.500 Zeichen
• Absätze gehen nicht über 3 bis 4 Sätze hinaus

Alternativ zum Erfassen in der Beschreibung kann auch ein To-Do-Plugin verwendet werden. In diesem Fall werden die Akzeptanzkriterien dann als einzelne Einträge dargestellt, die Sie auch abhaken können.

Tipp: Ein geeignetes Plugin zur Erfassung der Akzeptanzkriterien in Jira ist z.B. Acceptance Criteria for Jira von HeroCoders.

Für den Start mit der Arbeit mit Jira Akzeptanzkriterien ist das Beschreibungsfeld allerdings ausreichend.

Tipp 3: Wenn es mal zu viel wird: Stories aufteilen

Auch wenn Sie die zuvor beschriebene Hierarchie verwenden, werden einige Stories zu groß sein. Aber was genau bedeutet zu groß?

Ist eine Story zu groß, dann kann sie nicht in einem angemessenen Zeitrahmen umgesetzt werden und auch die Schätzung des Aufwands oder Komplexität ist schwierig bis gar nicht machbar.

Wenn Sie als Product Owner nach dem Scrum Framework arbeiten, ist Ihr Maßstab ein Sprint. Eine Story sollte so beschrieben werden, dass sie im Rahmen eines Sprints umsetzbar ist.

Lesetipp: Scaled Agile Framework (SAFe) – wie Sie Ihre Organisation agiler gestalten

Arbeiten Sie ohne Sprints, dann können Sie mit dem Team zusammen herausarbeiten, wie umfangreich eine Story maximal sein sollte. Meistens einigen sich Teams darauf, dass Stories innerhalb von 2 Wochen abgearbeitet werden sollten.

Wie teile ich eine Story in Jira auf?

Um eine Story in Jira aufzuteilen, können Sie die Split-Funktion verwenden. Klicken Sie dazu im Backlog mit der rechten Maustaste auf Ihre Story und dann im sich öffnenden Kontextmenü auf Split issue.

Daraufhin öffnet sich dieses Dialogfenster:

Für unsere Beispiel-Story wollen wir hier das Korrekturlesen und auch die Veröffentlichung in separaten Stories behandeln. Zu den beiden Stories gehören noch weitere Aufgaben. Zum Beispiel gehört bei der Veröffentlichung auch dazu, dass Links auf dem Blogbeitrag hinzugefügt werden und der Beitrag in die Seitenstruktur aufgenommen wird.

Für unsere ursprüngliche Story – das Erstellen des Beitrags – ist das nicht mehr relevant. Wir können das Erstellen des Beitrags als fertig betrachten, auch wenn der Blogbeitrag noch nicht veröffentlicht worden ist.

So lässt sich eine Story in sinnvolle Zwischenschritte unterteilen.

Wie kann die Story sinnvoll aufgeteilt werden?

In dem vorherigen Beispiel wurde die Aufteilung aus logischer Sicht vorgenommen. Wir haben drei Stories, die sich am Prozess der Veröffentlichung orientieren:

• Schreiben des Beitrags
• Korrekturlesen
• Veröffentlichung

Aber auch das Schreiben des Beitrags hätte bereits in mehrere Stories unterteilt werden können. Zum Beispiel in:

• Schreiben der Einleitung
• Schreiben von Tipp 1
• Schreiben von Tipp 2
• Schreiben von Tipp 3
• Integration von Bildern
• Erstellen des Fazits

Hier wäre die Unterteilung in die einzelnen Arbeitsschritte erfolgt. Das kann zum Beispiel dann erfolgen, wenn unterschiedliche Teams an einer Story arbeiten. Oder wenn ein Teil für einen Sprint geplant wird und der Rest erst später. So könnte der Beitrag über mehrere Sprints hinweg entstehen und die Stories könnten einzeln abgeschlossen werden.

Die Story könnte auch funktional aufgeteilt werden, z.B.:

• Schreiben eines Beitrags mit Tipps für Product Owner
• Recherche nach geeigneten Bildern

In diesem Fall wird die Story aufgeteilt in das eigentliche Schreiben und die Bilder-Recherche. Übertragen auf ein Software-Projekt heißt das:

• Implementierung der Backend-Funktionalität
• Bereitstellung eines Frontends zur Bedienung des Backends

Wie Sie sehen, gibt es viele Wege und Möglichkeiten, eine Story sinnvoll aufzuteilen. Besprechen Sie mit Ihrem Team, was am besten funktioniert und am hilfreichsten für Sie ist.

Wie stellen Sie Abhängigkeiten dar?

Wenn Sie eine Story aufgeteilt haben, ist dies sowohl in der ursprünglichen Story, als auch in den neuen Stories ersichtlich:

Über die Board-Konfiguration können Sie sich Abhängigkeiten auch im Backlog (oder auch auf dem Board) in Textform anzeigen lassen. Gehen Sie dazu in die Konfiguration (Board Settings) oben rechts:

Gehen Sie dann auf Card layout (1) und fügen Sie anschließend “Linked issues” bei der Backlog-Ansicht (2) hinzu. Vergessen Sie bitte nicht, auch auf “Add” (3) zu klicken.

Wenn Sie nun in das Backlog zurückgehen, werden die Abhängigkeiten unterhalb der Zusammenfassung mit ausgegeben.

So sehen Sie die Abhängigkeiten von Stories in Textform untereinander.

Fazit – der Einsatz von Jira als Product Owner ist einfach, aber…

Mit den zuvor genannten Tipps lässt sich Jira als Product Owner einfach anwenden. Stories lassen sich schnell und strukturiert erstellen. Im Zusammenspiel mit Confluence können Sie Anforderung transparent und nachhaltig erfassen.

Durch Beschreiben der Jira Akzeptanzkriterien ist ganz klar, was eine Story beinhalten muss. Und arbeiten mehrere Leute an einer Story oder wird die Story schlichtweg zu groß, lässt sie sich sehr einfach auf mehrere Stories aufteilen.

Doch wie bei so vielem: Der Teufel steckt im Detail.

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel zu Jira und Confluence ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master
• Teil 3: Jira für Product Owner (dieser Artikel)
• Teil 4: Jira für Developer
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

ARTIKEL DRUCKEN