Bevor wir das Thema öffnen, werden die Begriffe erklärt, mit denen wir im weiteren Verlauf arbeiten.

Epic

Agile Sicht

Epic ist in den agilen Methoden eine umfangreiche User story. Was bedeutet das? Praktisch gesehen können wir behaupten, dass es in den agilen Methoden reicht, Stories zu erstellen, die bestimmte Anwendungsfälle beschreiben. Oft kommt es aber dazu, dass viele User stories etwas Gemeinsames haben und gerade Epic dient dazu, diese Stories zu gruppieren. Epic ist also eine „Schüssel“, in der Bonbons einer Art sind, in der anderen Schüssel Bonbons anderer Art, zusammen jedoch bilden sie das Projekt „Süßigkeiten“ .

Diese Methode würde ich als bottom up bezeichnen, denn zunächst werden die kleinsten Einheiten (Stories) erstellt und dann werden sie in größeren Einheiten (Epics) gruppiert. In vielen Projekten aber funktioniert das top down Prinzip – zunächst werden größere Einheiten (Epics) erstellt – z.B. Produktfunktionalitäten und dann die kleinen Einheiten (Stories) – konkrete Bestandteile der jeweiligen Funktionalität.

Jirasicht

Wie schon erwähnt wurde, ist ein Epic eine ziemlich abstrakte Einheit. In Jira gibt es schon zwei abstrakte Einheiten (ohne Arbeitsablauf) – komponenten und Release (Versionen). Die Einführung einer dritten wäre wahrscheinlich kontraproduktiv, deswegen wurde Epic als Vorganstyp (issue type) eingeführt, d.h. er hat seinen Arbeitsablauf, seine Bildschirme und alles, was dazu gehört. Außerdem wurden spezielle Felder (Epic Name, Epic Link, Epic Status, Epic Colour – wie oft haben wir gemeckert, dass außer Summary noch Epic Name befüllt werden muss?), die agiles Arbeiten ermöglichen und auch spezielle Regeln eingeführt – im System gibt es nur einen Vorganstyp „Epic“. Es ist zwar möglich, diesen umzubenennen, aber wenn der Vorgang geöffnet wird, sehen wir trotzem „Issues in Epic“, obwohl Epic umbenannt wurde*. Es ist nicht möglich, einen Vorganstyp der Art „Epic“ zu definieren. Es gibt nur Standardvorgang und Unteraufgabe**.

_{*Es ist eine out-of-the-box Funktionalität, es gibt Apps, die dies ändern können.}

_{**Administratoren wissen, wovon die Rede ist} 

Scrumboard

Scrum ist eine agile Planungsmethode. In Jira wird auf dem Scrumboard gearbeitet, wo es möglich ist, Stories (und andere Vorganstypen außer Epic) zu erstellen, diese den Epics und Releases zuzuweisen und diese in Sprints zu planen. Und eben hier stoßen wir auf das Epicverhalten, dass als „unlogisch“ erscheinen kann.

„Ich habe das Epic doch geschlossen!“

So etwa sieht ein eingfaches Scrumboard aus:

Versuchen wir einen konkreten Fall zu beschreiben.

Auf dem Scrum board haben wir alle Stories, die zu einem bestimmten Epic gehören, geplant. Diese Stories wurden in den Sprints erledigt. Das bedeutet, dass dieses Epic für ein weiteres Planen nicht mehr notwendig ist, es muss also weg vom Scrumboard. Hier können zwei Fälle auftreten.

Fall Nr.1:

Wir nutzen die Funtkionalität, die auf dem Scrumboard eingabaut ist und schließen das Epic.

Epic verschwindet vom Board.

In meinen Filtern jedoch ist das Epic nicht als erledigt markiert, nach dem Öffnen steht dort ein anderer Status!

Fall Nr. 2:

Ich öffne das Epic und ändere den Status auf „Done“.

Ich öffne das Scrumboard und was steht dort? Das Epic ist immer auf dem Board.

Warum ist es so?

Das Geheimnis ist, dass der Arbeitsablaufstatus nicht darüber entscheidet, ob ein Epic auf dem Board ist oder nicht. Entscheidend ist das spezielle Auswahlfeld „Epic Status“, das auch Werte To Do, In Progress, Done beinhaltet. Im Fall Nr. 1, beim  „Mark as done“, ändert Jira den Wert in diesem Feld auf „Done“ und das Epic verschwindet vom Board. Der Arbeitsablaufstatus wird aber nicht geändert. Im Fall Nr. 2 wird der Arbeitsablaufstatus geändert, das Feld „Epic Status“ bleibt in Ruhe und es gibt keinen Grund, vom Board zu verschwinden.

Empfehlungen

Ratschlag Nr. 1:

Das Feld „Epic Status“ ist normalerweise nicht auf dem Epicbildschirm. Fügen Sie dieses Feld auf den Bildschirm. Über „Bearbeiten“ kann gelenkt werden, ob das Epic auf dem Board sein soll oder nicht. Hinweis – es besteht das Risiko – jemand kann den Wert des Feldes ändern, obwohl es nicht notwendig ist. Über „Bearbeiten“ kann der Wert aber zurück gesetzt werden.

oder

Ratschlag Nr. 2:

Sind Sie ein Administrator, fügen sie Post functions auf die Übergänge, die den Wert des Feldes Epic Status ändern. Sind Sie keiner, fragen Sie Ihren Administrator und erklären Sie ihm den Zweck. Der Arbeitsablauf entspricht dann immer dem Wert im Feld „Epic Status“. In diesem Fall aber Ratschlag Nr. 1 nicht befolgen.

Zum Schluss

Es gibt auch ein anderes Szenario: Sie sind mit dem Epicverhalten vällig zufrieden und Sie brauchen keine Änderung. Das ist auch absolut in Ordnung . Dieser Blogeintrag dient der Erklärung, warum sich Epics so verhalten und was geändert werden kann, wenn der Benutzer damit nicht einverstanden ist. Sollten Sie andere Ratschläge haben, sind Ihre Kommentare willkommen.

Schlussbemerkung: dies gilt nicht für Next-gen Projekte in Jira Cloud, dort werden Epics nicht im Board geschlossen und deren Arbeitsablauf ist auch nicht für Änderungen verfügbar.

Radim Drinka
Atlassian Certified Technical Sales

Wenn Sie Hilfe von Experten bei der Implementierung oder Einrichtung von Jira benötigen oder Ratschläge, wie Sie es in Ihrem Unternehmen am effizientesten einsetzen können, wenden Sie sich an uns. Wir werden Sie unterstützen.

Unsere Atlassian Lösungen