Wer Jira (oder irgendeine andere beliebige Software) nutzt, ist sehr wahrscheinlich schon dem Begriff der »Epics« begegnet. Ist das sinnvoll? Brauche ich das? Wie unterscheidet sich das von Komponenten? Wenn das jeder im Unternehmen anders macht, kriegen wir wahrscheinlich ein Problem, wir sollten uns also auf ein gemeinsames Vorgehen einigen.
Zuerst einmal sind weder Epics noch Komponenten in irgendeiner Form in der Scrum Welt verankert. Der Scrum Guide schweigt sich zu diesen beiden Begriffen komplett, was nur bedeutet, dass sie nicht Bestandteil des offiziellen Regelwerks sind und ich sie daher nicht nutzen muss. Was jedoch nicht bedeutet, dass ich sie nicht nutzen kann oder sogar sollte.
Die Schwierigkeiten der meisten Teams beginnen damit, das die Begriffe nicht definiert sind. Das hat manchmal zur Folge, dass man sich seine eigene Definition macht und Funktionen einer Software nutzt, weil sie da sind, und dann diese Funktionen irgendwie in das Vorgehen (also die eigene Scrum Implementierung) übernimmt. Für mich klingt das irgendwie nicht richtig.
Unter einem Epic versteht man im allgemeinen nichts weiter als eine Projektklammer für mehrere zusammengehörige Aufgaben/Stories/Anforderungen. Ein Beispiel: Wir bauen Amazon nach. Der gesamte Bestellvorgang ist sehr wahrscheinlich zu groß und zu komplex, als dass ich ihn in einer Aufgabe abbilden und entwickeln könnte, die ich innerhalb eines Sprints erledigen kann. Unter dem Oberbegriff »Bestellvorgang« könnte ich aber alle Aufgaben zusammenfassen, die fachlich diese übergeordnete Funktionalität ergeben. Damit wäre »Bestellvorgang« mein Epic, unter dem ich viele Aufgaben wie »Zahlungsauswahl«, »Lieferadressauswahl« oder »Bestätigungsmail« und viele mehr finden könnte. Jede einzelne dieser Aufgaben wäre eine Anforderung, die innerhalb eines Sprints umzusetzen ist, während das Epic »Bestellvorgang« mir über mehrere Sprints erhalten bleibt.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Dahinter steckt die einfache Tatsache, dass viele Anforderungen, die wir umsetzen möchten, viel zu groß und zu komplex für eine einzelne Aufgabe sind, die wir innerhalb eines Sprints bearbeiten könnten. Einen Nutzen generieren wir jedoch nur, wenn wir viele Aufgaben zusammenfassen und erledigen, die eine gemeinsame Funktionalität ergeben. Unser Epic ist damit zu erstellende Funktionalität.
In meinem Backlog hilft mir das dabei, nach zusammengehörigen Aufgaben zu filtern – nicht mehr und nicht weniger. Was die Software betrifft, ist ein Epic also ein ganz simples Ordnungsinstrument.
Für mein Vorgehen im Team, in der Entwicklung selbst, sind Epics jedoch wichtig, weil ich sowieso in größeren Einheiten denke. Wenn wir ein Projekt entwickeln, beginnen wir meistens damit, die groben Eigenschaften, Funktionalitäten oder Bereiche aufzulisten. Innerhalb dieser einzelnen Punkte gehen wir dann tiefer ins Detail und leiten eine Reihe von Aufgaben ab.
Wenn wir beim Beispiel Amazon nachzubauen bleiben, würden wir ein grobes Backlog aufbauen, in dem wir Punkte wie »Suche«, »Accountverwaltung« und »Bestellvorgang« anlegen. Jeder einzelne dieser Punkte ist größer als eine Aufgabe, die ich innerhalb eines Sprints abarbeiten könnte. Zusätzlich ist es vielleicht nicht die beste Idee, alles gleichzeitig angehen zu wollen. Wir schnappen uns für unser Refinement also das Epic, das in unserer Priorität ganz oben steht, nehmen es auseinander und erstellen einzelne Aufgaben, die wir dem Epic zuordnen. Auf diese Art strukturieren wir nicht nur das Backlog sondern vor allem das Vorgehen, und genau das möchte ich ja erreichen.
Epics sind also für uns eine Hilfe, vom Groben ins Feine zu gehen. Sie helfen uns, das Backlog zu ordnen, und bilden eine Klammer, mit der mehrere Aufgaben zusammengefasst werden, die eine gemeinsame Funktionalität bilden.
Es haben sich zwei grobe Vorgehensmuster herausgebildet. Die einen legen Epics an, priorisieren diese, erstellen in Refinements daraus die Aufgaben und füllen erst dann ihr Backlog mit den fein ausgearbeiteten konkreten kleinen Anforderungen. Der Vorteil dieses Vorgehens liegt darin, dass ein Backlog so übersichtlich, kurz und sauber bleibt. Kurz gesagt: man schleppt nicht so viel Müll mit sich rum. Der Nachteil liegt darin, dass ich auch meine Epicliste pflegen und priorisieren muss.
Die andere Option ist das klassische Vorgehen, in dem Dinge, die noch weit entfernt sind, als Oberbegriff einfach unten ins Backlog eingekippt werden. Rücken diese Dinge näher, werden sie feiner ausgearbeitet. Der Oberbegriff wird dann in ein Epic umgewandelt und im Backlog durch die feiner ausgearbeiteten Aufgaben ersetzt. Ein Vorgehen nach diesem Muster wird von der Scrum-Polizei gern gesehen, weil es eher dem Scrum Guide entspricht. Der Vorteil liegt darin, dass alles in meinem Backlog zusammengefasst ist. Der Nachteil liegt darin, dass es vielleicht ein wenig unübersichtlicher ist.
Wenn ihr mich nach meiner Empfehlung fragt, tendenziell Option B, wobei ich den Weg A nicht sofort als Teufelszeug verdammen würde. Es kommt auf das Team und das Projekt an. Wenn ich sehr diszipliniert damit umgehen kann, wenn ich die Epics gut voneinander trennen kann, und das für alle Beteiligten gut funktioniert, dann macht es so, wie es für Euch am besten passt.
In der Konsequenz helfen uns Epics auch dabei, unsere Sprints nicht zu wild zu mischen. Wir füllen unser Sprints nicht mit »oh, da ist eine Aufgabe, die so groß ist, das sie noch genau reinpasst« sondern mit fachlich zusammengehörigen Aufgaben, die gemeinsam einen Nutzen generieren, also gemeinsam eine Funktionalität erstellen, die wir mit unserem Sprintziel ausdrücken. Das wird einfacher, wenn ich die Krücke Epic nutze.
Neben Epics kennt Jira (als stellvertretendes Beispiel für weitere Software) auch den Begriff der »Komponente«. Wenn ich Epics als fachliche Klammer verstehe, dann die Komponenten als technische. Schließlich sprechen wir auch von Komponententeams. Diese Eselsbrücke können wir weiterhin benutzen.
Eine Aufteilung meiner Aufgaben in technische Gruppen ist natürlich sofort sinnvoll, wenn ich mit mehreren Komponententeams an einem gemeinsamen Projekt arbeite. So könnte ich im gemeinsamen Backlog sehen, welches Team sich um welche Aufgabe kümmern wird.
Darüber hinaus muss ich leider sagen, dass ihr selbst entscheiden müsst, ob Ihr technische Filter innerhalb Eurer Aufgaben braucht. Frontend – Backend ist für die meisten zu simpel. Eine Zuordnung zu einzelnen Komponenten in Eurer Architektur? Kann man machen, aber auch das braucht man meistens nicht. Habt ihr viel mit Microservices gemacht, kann das schon sinnvoller werden. Innerhalb eines Teams werden die Komponenten eher selten wirklich gebraucht. Die meisten Teams kommen auch ohne ganz gut zurecht, aber entscheidet bitte selbst, ob ein technisches Filtern für Euch Sinn macht und ob Euch das Euer Leben erleichtert.
Schwierig wird es immer, wenn wir Fachlichkeit und Technik miteinander vermischen. Obwohl Ihr alle Freiheiten habt, wie Ihr Epics und Komponenten nutzen wollt, solltet Ihr darauf achten, bei der Trennung von Technik und Fachlichkeit sehr konsequent zu bleiben. Finden sich bei den Epics plötzlich auch technische Eigenschaften, muss ich bei jeder Aufgabe, die ich dort hinzufüge, noch die Frage stellen, wo sie jetzt fachlich hingehört. Bitte glaubt mir: das wollt Ihr vermeiden.
Kernaussagen: Epics sind fachliche Klammern innerhalb des Backlogs, mit dem mehrere Aufgaben, die gemeinsam eine Funktionalität ergeben, zusammengefasst werden. Sie sind damit ein Ordnungsinstrument. Im Gegensatz dazu sind Komponenten technische Klammern, mit denen mehrere Aufgaben zusammengefasst werden, die demselben Komponententeam zugehörig sind oder gemeinsame Bereiche der Architektur nutzen.
