3 Jira Tipps für Product Owner, die Sie kennen sollten

0

Mit dem agilen Produktframework Scrum kam auch die Rolle Product Owner in das Projektmanagement-Geschäft. Dieser Artikel enthält 3 Tipps für Sie in der Rolle als Product Owner im Umgang mit dem Projektmanagement Tool Jira.

Das sind die Themen, die auf Sie warten: 

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
  • u.v.m.

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 Owners wird mittlerweile in vielen Projekten eingesetzt – auch bei denen, die nicht auf dem Framework Scrum basieren, sondern lediglich Elemente daraus bedienen. Der Aufgabenbereich der 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 Owners 

Wie einleitend 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 mit Hilfe von Jira umgesetzt werden. Der Schwerpunkt von Jira liegt dabei auf der Formulierung der Anforderungen und der Erstellung der Roadmap. 

Lesetipp: Project Roadmap – was kann das neue Online-Tool wirklich?

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. Alles Aufgaben, die Sie als Product Owner in Jira abbilden können. Und selbst 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. Es gilt jedoch zu beachten, dass die Stories in Jira mit den Anforderungen in Confluence verlinkt werden. 

Was ist der Vorteil des Einsatzes von Confluence? 

Wenn Sie die Anforderungen in Confluence beschreiben, haben Sie dort auch die geeignete Stelle der 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 auch abgehakt werden 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 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 mit Scrum als 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 werden Abhängigkeiten dargestellt? 

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 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. 

Haben wir Tipps für den Product Owner vergessen? Dann schreiben Sie uns gerne in den Kommentaren! 


Antje Lehmann-Benz (PMP, PMI-ACP, PSM Expertin / Trainerin für Agile Methoden)  – Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderem Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.


Patric Eid – Patric Eid ist seit 2013 selbstständiger Trainer, Berater und Agile Coach für Projektmanagement mit Schwerpunkten auf hybriden und agilem Projektmanagement, Scrum und Software-Trainings (u.a. Jira). Zuvor arbeitete er selbst in den Rollen Scrum Master, (agiler) Projektleiter und Software-Entwickler und lässt diese Erfahrungen in seine Beratungsmandate und Trainings mit einfließen.

 

Mehr zu Patric Eid auf LinkedIn.

ARTIKEL DRUCKEN

Share.

Kommentar abschicken