Die Unterschiede zwischen Epic, User Story und Task in Atlassian Jira

Juli 2020

In der täglichen Arbeit mit Jira können die verschiedenen Arten von Issue Types verwirrend sein. Wozu ist ein Epic hilfreich? Wann wird eine Story angelegt und worin unterscheiden sich Tasks und Sub-Tasks? Auch wenn es nicht die eine richtige Antwort gibt ist es sinnvoll, eine einheitliche und klare Definition für das Team festzulegen, damit es eine übersichtliche Struktur der verschiedenen Themen und Aufgaben im Backlog und im Scrum oder Kanban Board geben kann.

Um eine Definition der verschiedenen Arten von Issue Types zu finden, sucht man diese selbst im Scrum Guide vergeblich. Denn dieser fasst die Aufgaben lediglich als Product Backlog Items (PBI) zusammen. Jedoch ist eine sinnvolle Struktur über verschiedene Hierachie-Level vor allem bei größeren und komplexen Projekten sinnvoll um die zu erledigenden Aufgaben übersichtlich abzubilden. Auch wenn es im Scrum Guide keine Definition dafür gibt, sind vor allem die Verwendung von Epics und User Storys als Best Practice anzusehen und helfen, dem Product Backlog eine Form zu geben. Aber worin unterscheiden sich die verschiedenen Typen genau?

Epic

Ein Epic beinhaltet eine Vielzahl von Arbeiten, die erledigt werden müssen, um das Epic fertig zu stellen. Ein Epic ist an sich auch eine User Story, die aber so groß ist, dass sie in mehrere kleinere User Stories aufgeteilt wird. In einem Projekt ist ein Epic dazu da, um bestimmte Anforderungen und Funktionen thematisch zusammen zu fassen. Wie genau diese Themen zusammengefasst werden, hängt vom Thema an sich ab und ist somit projektspezifisch. Die Epics sind in der Regel so angelegt, dass sie alle wichtigen Themen sinnvoll gruppieren, um in dieser ersten Hierachiestufe eine grobe Übersicht der geplanten Themenbereiche zu geben.

Folgende Themen können zum Beispiel ein Epic beschreiben:

  • Userverwaltung
  • Bestellverwaltung
  • Checkout
  • ERP

Die Fertigstellung eines Epics wird in der Regel über mehrere Sprints verteilt. Durch die Aufteilung der Arbeiten in einzelne User Stories besteht somit die Möglichkeit, die einzelnen Arbeiten zu priorisieren.

Mehr zu dem Thema

Epic in der offiziellen Atlassian Dokumentation →

User Story

Eine User Story beschreibt eine Anforderung im Projekt, die sich in einem kurzen einfachen Satz zusammenfassen lässt. Dieser Satz ist so formuliert, dass er für jede Person verständlich ist und beinhaltet daher auch keine technischen Informationen. Beispiel für so eine Formulierung kann folgender Satz sein:

Als Gast möchte ich mich registrieren können, um auf den geschützen Seitenbereich zugreifen zu können.

Die Formulierung ist immer nach dem folgenden Schema aufgebaut:

Als (Rolle) möchte ich (Ziel/Wunsch), um (Nutzen).

Die Stories sind mit dem Epic verknüpft, so dass direkt ersichtlich wird, welche Ziele (Funktionen) zu einem Epic gehören. Ebenfalls ist so direkt ersichtlich, wie weit die Umsetzung des jeweiligen Epics fortgeschritten ist bzw. welche Funktionen noch fertig gestellt werden müssen.

Mehr zu dem Thema

User Story in der offiziellen Atlassian Dokumentation →

Task & Sub-Task

Generell unterscheidet Jira zwischen zwei Arten von Tasks:

  • Task
  • Sub-Task

Der Unterschied zwischen diesen beiden ist das Hierachie-Level, in dem die Issues einsortiert werden. Ist ein Issue mit dem Typ Task auf der gleichen Hierachie-Stufe wie eine Story. Sowohl eine Story als auch ein Task können beide wiederum Sub-Taks, also Unteraufgaben beinhalten. Ein Sub-Task ist somit die unterste Aufgaben-Ebene.

Mehr zu dem Thema

Task in der offiziellen Atlassian Dokumentation →

Story oder Task?

Um zu entscheiden, ob eine Story oder ein Task verwendet wird, lässt sich die Entschweidung wie folgt treffen:

Eine Story wird dann verwendet, wenn es ein auf den Benutzer ausgerichtetes Feature im Projekt, z.B.

  • Benutzer Anmeldung
  • Passwort Vergessen Funktion
  • Login mit Google
  • usw.

Die Umsetzung dieser Story bringt einen eindeutigen Wert in das Projekt. Innerhalb dieser Story können dann beliebige Sub-Tasks erstellt werden, die weitere konkrete Aufgabenpakete innerhalb der User Story beschreiben und von den einzelnen Fachabteilungen umgesetzt werden.

Ein Task wird hingegen verwendet, wenn es keine spezifischen Features betrifft, sondern vorbereitende Themen oder parallele Aufgaben, die erledigt werden müssen, z.B.

  • Git-Repository einrichten
  • Deployment-Pipeline aufsetzen
  • Grundlegende System-Architektur zusammenstellen
  • Projektmanagment & Controlling
  • usw.

Theoretisch können diese Aufgaben ebenfalls als Story angelegt werden. Auch wenn die Aufgaben für das Projekt wichtig und notwendig sind, fügen sie jedoch keinen für den Benutzer spürbaren Mehrwert dem Projekt hinzu.

Zusammengefasst lässt sich also festlegen, dass ein (Sub) Task immer eine klare Aufgabe zur Umsetzung beinhaltet. Eine Story auf der anderen Seite beschreibt lediglich das Feature aus Benutzersicht. Die Arbeit an einer Story wird in der Regel auch von mehreren Fachabteilungen durchgeführt, die Fertigstellung eines (Sub) Taks wird hingegen von einer konkreten Fachabteilung (z.B. Entwicklung) durchgeführt.

Bei der Arbeit mit Jira ist zu beachten, dass Sub-Tasks im Backlog nicht angezeigt werden und können auch nicht als einzelne Aufgabe in einen Sprint eingeplant werden. Sub-Tasks eignen sich daher meistens nur, wenn die Story innerhalb eines Sprints fertig gestellt werden kann. Gibt es zu viele Sub-Tasks, kann es eventuell sinnvoll sein, die zu große Story auf mehrere kleinere zu verteilen, die dann auch unabhängig voneinander in verschiedenen Sprints eingeplant werden kann.

Fazit

Bei der täglichen Arbeit mit Jira gibt es einige Dinge zu beachten, damit die geplanten Aufgaben bearbeitet werden können. Auch wenn die verschiedenen Issue Types auf den ersten Blick gerade Jira-Neulinge verwirren, können Sie helfen, die Arbeit in eine gewisse Struktur zu bringen. Auch wenn die zuvor beschriebene Sicht auf die Struktur nur eine mögliche Option und nicht die Musterlösung darstellt, ist es vor allem wichtig, für sich und das gesamte Team eine funktionierende Variante zu finden. Durch die Flexibilität von Jira stehen hier auch viele Möglichkeiten offen, um die Struktur nach den eigenen Wünschen und Anforderungen anzupassen.

Tags

Jira
Chris van Daele

Chris van Daele

Ich bin Fachinformatiker in der Fachrichtung Anwendungsentwicklung und arbeite aktuell als technischer Projekt Manager im Bereich E-Commerce und Individualentwicklung. Zum Profil