Share ZU:
2 January 2019 @ Bertil Muth

Epics sind tot

Was wurde nicht schon alles für tot erklärt? Schon vor Jahren wurde Test Driven Development beerdigt. Merkwürdigerweise verbreitet es sich trotzdem immer weiter. Natürlich ist auch Agil tot. Obwohl  selbst traditionsreiche Unternehmen mittlerweile mit Scrum in Berührung gekommen ist.
Totgesagte leben länger, sind aber immer gut für eine schmissige Überschrift.
In diesem Sinne. Werden Sie Zeuge, wie ich Epics als agile Praktik zerstöre.

Was sind Epics?

Der Begriff ist schwammig. Das hat Vorteile: Epics dienen eher der Kommunikation, als der Spezifikation. Die Schwammigkeit macht sie vielseitig einsetzbar.
Auf der anderen Seite besteht die Gefahr von Missverständnissen. Ich halte mich an Mike Cohns Definition:

A Scrum epic is a large user story.

(Mike Cohn über Epics)

Genauer: Ich verstehe unter einer Epic eine Story, die zu groß ist, um in einem Scrum-Sprint (von vielleicht 2 Wochen) umgesetzt zu werden.
Die Elemente ganz oben im Product Backlog sind daher keine Epics, sondern kleine Stories. Weiter unten im Backlog finden sich dann typischerweise Epics. Nach und nach werden die Epics in Stories “kleingeschnitten” , die in einem Sprint umgesetzt werden können.
So habe ich das jahrelang in meinen Trainings gelehrt, und es scheint der allgemeine Konsens zu sein.  Auf den ersten Blick intuitiv. Genauer betrachtet aber unpraktikabel.

3 unpraktikable Wege, mit Epics umzugehen

Ich bin bisher auf drei Wege gestoßen, wie Unternehmen mit Epics umgehen. Keiner von ihnen ist praktikabel. Nennen wir sie:

1. Auflösung
2. Verknüpfung
3. Baum

1. Die Auflösung

Das Prinzip der Auflösung ist einfach: ein Epic wird vollständig in seine Bestandteile, die einzelnen kleinen Stories zerlegt.
Ein Epic “Flug buchen” eines Online-Flugportals könnte zum Beispiel in die einzelnen Prozessschritte zerlegt werden. Also “Anmelden”, “Flug suchen”, und so weiter. Jeder Prozessschritt wird zu einer Story. Die wird geschätzt. Ist sie zu groß für einen Sprint, wird sie weiter kleingeschnitten.
Wenn man das Epic vollständig in User Stories aufgelöst hat, löscht man das Epic und startet die Entwicklung für die Stories.
Mich stört daran der Gedanke der Vollständigkeit. Die Auflösung suggeriert, dass ein Thema mit einem vorab festgelegten Scope abgeschlossen werden kann. Wie in einer Checkliste: Haken dran.
Eine vollständige Auflösung vor der Entwicklung ist aber nicht möglich, wenn auch während der Entwicklung Änderungen an den Stories möglich sein sollen. Und das ist essentiell für das agile Arbeiten.

Der Scrum Guide schreibt dazu:

Ein Product Backlog ist niemals vollständig. […] Anforderungen werden nie aufhören, sich zu ändern.

Wenn man zwangsläufig einen fixen Scope liefern muss, kann man sich das Theater mit den Epics auch sparen, und die Anforderungen vorab detailliert beschreiben wie in der guten alten Zeit im Lastenheft.

2. Verknüpfung

Folgt man dem Weg der Verknüpfung, verzichtet man auf die vollständige Auflösung. Das heißt: Die Epics bleiben bestehen, unten im Backlog. Neue, kleine Stories werden mit den Epics verknüpft, aus denen sie sich ableiten. 
Das Risiko besteht darin, dass sich über die Zeit ein immer größerer Bodensatz an Epics entsteht. Das Backlog enthält Epics, die nicht aktiv weiterbearbeitet werden. Zum Beispiel weil der Stakeholder nicht mehr im Unternehmen ist, oder das Thema nicht mehr relevant.
Dem kann entgegengewirkt werden, indem das Backlog regelmäßig aufgeräumt wird. Das betrachte ich als nicht wertschöpfende Arbeit, die besser in die Umsetzung fließen sollte.
Verknüpfung bedeutet also Aufwand, der vermieden werden sollte. Und auch kann, wie ich noch beschreiben werde.

3. Baum

Ein weiterer Weg ist die Darstellung von Epics und Stories als Baum:

Darstellung Epic Stories als Baum

Die kleinen Stories werden also nach Epics gruppiert. Keine schlechte Idee. Was aber verloren geht, ist die geordnete Listen-Sicht auf das Backlog. Wie wird dann die Implementierungsreihenfolge festgelegt?
Natürlich kann man jetzt ein digitales Werkzeug verwenden, das beide Sichten unterstützt. Das Risiko: es wird zu viel Zeit und Aufwand in die Werkzeuge investiert.
Was sind die Sichten? Was sind die Attribute? Was ist das zugrundliegende Datenmodell? Alles Fragen, die berechtigt sind. Aber in einem agilen Vorgehen sollten sie keinen hohen Stellenwert haben.

Zusammengefasst ist die Idee der Gruppierung gut, die Umsetzung aber unnötig aufwändig.

Die Alternative zu Epics

Es gibt schon lange eine Alternative. Sie wird sogar im selben Blogbeitrag von Mike Cohn erwähnt, den ich oben verlinkt habe.

Die Rede ist von Themes (Themen).

Ein Thema kann man sich als zusätzliches Attribut der Stories vorstellen. Normalerweise haben mehrere Stories das gleiche Thema. Die Story  “Flug suchen” könnte als Thema also “Flug buchen” haben. Ein Ausschnitt aus dem Backlog sieht dann wie folgt aus:

User Stories mit Thema

Themen werden also nicht wie Epics als separate Backlog-Elemente verwaltet. Dadurch entfallen die Aufräumarbeiten, die im Kapitel Verknüpfung besprochen wurden. Das ist gut.
Was aber verloren geht, ist der Prozess der schrittweisen Verfeinerung von den großen Epics zu den Stories, die in einem Sprint umgesetzt werden können. Das ist schlecht.
Zum Glück gibt es Praktiken, die es möglich machen, diese Verfeinerung außerhalb des Backlogs durchzuführen. Für die Identifikation von Themen bietet sich ein Use-Case-Diagramm an:

Das schöne an solchen Diagrammen ist, dass sie durch hohe Flughöhe und die graphische Darstellung das “Big Picture” erkennen lassen. Dafür ist ein Backlog ungeeignet.
Aus den Use-Case-Namen werden später im Backlog Themen. Aber wie kommt man von den Use Cases zu den Stories? Dafür ist Story Mapping sehr geeignet:

Story Map für die Use Cases “Flug buchen” und “Profil verwalten”

Die obersten beiden Zeilen der Beispiel-Map zeigen hier die Use Cases “Flug buchen” und “Profil verwalten” und ihren Normalablauf (Basic Flow). Unter die einzelnen Schritte werden die Alternativen gehängt, also andere Abläufe, Fehler und so weiter. Diese gelben Zettel nennt man User Tasks.
Im Backlog Refinement werden aus den User Tasks die Stories abgeleitet. Ein Task kann dabei als Titel der Story dienen. Die Stories werden ein wenig ausformuliert. Dann werden sie mit Akzeptanzkritieren versehen.

Die Konsequenzen

Wendet man dieses alternative Vorgehen an, hat das Konsequenzen. Zum Beispiel, dass das Product Backlog nur noch Stories für die nächsten 1-2 Sprints enthält. Also vielleicht 10-20 Stories.
Alle Aktivitäten wie weitergehende Priorisierung, Schätzung  und Ausarbeitung der Akzeptanzkriterien finden nur noch anhand dieser Stories statt. Ganz im Einklang mit dem 10. Agilen Prinzip:

Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.

Wenn das Management Einblicke in den Fortschritt der Entwicklung haben will, ist das mit obigem Vorgehen auf drei Ebenen möglich:

  1. Use-Case-Diagramme bzw. Themes bieten die langfristige Perspektive für das Management. Für 1 Jahr, oder sogar darüber hinaus. Aber: für das Festlegen von Details sind sie nicht geeignet.
  2. Story Maps bilden die Grundlage für die Releaseplanung. Stakeholder, die Interesse am Release haben, erstellen gemeinsam mit Teammitgliedern die Story Map. (Der Scope kann sich aber aufgrund neuer Erkenntnisse auch während der Entwicklung noch ändern.)
  3. Wer einen tiefen Einblick haben und Einfluss auf die Details während der Entwicklung nehmen will, beteiligt sich am Sprint Review und am Backlog Refinement.

Nur in geringer Flughöhe sehen wir die Details. Und das Product Backlog ist im Grunde wie ein Einkaufszettel: Schreiben Sie auf, was Sie erst in einem Jahr kaufen wollen?
Last, but not least läutet der Tod der Epics das Sterben der Konsumentenhaltung ein. Wer etwas haben will, muss sich mit dem Team einigen und eng zusammenarbeiten.

Post Mortem

In der Diskussion mit Kollegen wurde ich darauf hingewiesen, dass auch nach einer Auflösung eines Epics neue, kleine Stories hinzukommen können. Das ist richtig, und für mich eine akzeptable Lösung. Was in diesem Fall jedoch verloren geht, ist das “Big Picture”, wie ich es im Use-Case-Diagramm gezeigt habe.
Letzten Endes entscheidet aber die Eignung eines Produktes für die Nutzer über seinen Erfolg. Nicht, wie es hergestellt wurde. Das trifft auf alle Entwicklungspraktiken zu, also auch auf Epics.
Vielleicht haben Sie ja für sich einen sinnvollen Weg gefunden, mit Epics umzugehen? Dann lassen Sie es mich in den Kommentaren wissen.

Übrigens: der Erfinder der Story Maps, Jeff Patton, ist in diesem Jahr Keynote Speaker auf unserer Tagung, der ReConf. Ich halte zusammen mit Philip Stolz dort ebenfalls einen Vortrag. Sehen wir uns?

Bertil Muth

Kontaktieren Sie Bertil Muth

Bertil Muth arbeitet als Agiler Coach, Scrum Master und Trainer. Mit Leidenschaft setzt er sich für konstruktive Zusammenarbeit, dezentralisierte Entscheidungsfindung und technische Exzellenz in der Produktentwicklung ein.