Ein Scrum EPIC richtig schreiben (Jira und SAFe)

Scrum EPIC
Von Sebastian Schneider // 23.10.2021 // 0 Kommentare

Wie schreibst du dein perfektes EPIC in Scrum, wie legst du es in Jira an und was ist beim SAFe EPIC anders? Diese Fragen ziehen sich durch meine Arbeit in Unternehmen und ich teile in diesem Beitrag meine Erlebnisse und Erkenntnisse aus der Praxis, die du zur Reflexion ideal nutzen kannst.

Ich zeige dir die Grundlagen zum EPIC, wie du es schreibst und wie es im Jira Tool gehandhabt wird und zu guter wie es im Scaled Agile Framework zu verstehen ist.


EPICs schreiben und richtig anwenden: Inhaltsverzeichnis

Was ist ein EPIC?

Ein EPIC in Scrum beschreibt eine Anforderung. Unter einem EPIC wird in Abgrenzung zur User Story (die auch Anforderungen beschreibt) in der Regel eine große Anforderung verstanden, die nicht in einen Sprint umsetzbar ist. Zudem ist der Detallierungsgrad meistens (noch) recht grob. Wenn du dem DEEP Akronym folgst, also alles das, was weit unten in einem Product Backlog stehen würde.

Damit ist ein EPIC in Scrum ein großer Block an Arbeit, der zusammenhängend ein bestimmtes Ziel hat. In recht kompakter Form beschreibt ein EPIC damit eine beliebige Anforderung an ein System, für ein Produkt oder auch Dienstleistung - je nachdem was dein Team entwickelt.

In der folgenden Darstellung kannst du die Idee des EPICs als Container ganz gut begreifen. So kann man das EPIC in Scrum verstehen: es gruppiert mehrere User Stories zu einem bestimmten Bereich.

EPIC als Container

Ein anderer Ansatz ist es, das Scrum EPIC selbst als lebendiges und emergentes Element zu betrachten. Dabei geht es mir weniger um dogmatische Haarspalterei sondern um einen Impuls, der sich auch gar nicht mit der ersten Abbildung beißen muss.

Solange etwas größer ist, als was wir in einem Sprint umsetzen können, nennen wir es EPIC. Soweit klar. Jetzt können wir das ganze auch als emergenten und organischen Vorgang betrachten, bei dem ein Scrum EPIC so lange in einem "größer als ein Sprint" Kontext bewegt, bis wir mehr Klarheit bekommen haben, um zu sagen, was wir brauchen, damit es in einem Sprint umgesetzt werden kann.

Ein emergentes EPIC in Scrum

Wie du ein EPIC formulieren kann

Ein EPIC zu schreiben ist im Grunde recht einfach, da es keine zwingende Notation benötigt. Viele nutzen auch hier das Format einer User Story, wohl wissend, dass es eben deutlich größer ist. Mögliche EPIC Beispiele findest du im nächsten Absatz. 

Beispiel für ein EPIC

  • Als Vermittler einer Versicherung möchte ich alle verfügbaren Tarife eines Anbieters aufrufen und vergleichen können.
  • Alle Systeme unseres Unternehmen nutzen Two-Factor Authentication (2FA), um die Sicherheit zu erhöhen.
  • Anbindung Vertriebsplattform

Wie du schon siehst, sind selbst diese drei einfachen Beispiele für EPICs sehr unterschiedlich. Von einem schon eher klaren Verständnis, über große Ideen bis hin zu Stichworten kann ein EPIC alles sein.

Aufbau eines Scrum EPIC

Aus meiner Sicht gibt es (zum Glück) nicht den einen Aufbau für ein Scrum EPIC, aber durchaus viele Varianten, die in jeweiligen Kontexten in Unternehmen zum Ziel führen können. Ich möchte dir im Folgenden ein paar Impulse geben, wie so etwas aussehen kann. Schau die die folgenden Scrum EPIC Informationen an, in wie weit du sie verwenden kannst.

  • EPIC ID. Eine eindeutige Kennzeichnung des EPICs in Form einer ID, Zahl oder sonstigen Markierung, um es eindeutig zu identifizieren.
  • EPIC Titel. Ein kurzer knackiger Titel, der den Inhalt des Scrum EPIC beschreibt und sich möglichst schnell einprägt.
  • EPIC Beschreibung. Eine Beschreibung des EPIC im Inhalt. Hier muss eine gute Balance gefunden werden, um 
  • EPIC Risiko. Eine Größe um ein Risiko für das EPIC zu bestimmen. Das Risiko kann und wird unterschiedlich interpretiert, kann relativ geschätzt oder auch absolut geschätzt werden. Je nachdem, was das Unternehmen auch ermöglichen kann.
  • EPIC Aufwand / Größe / Komplexität / .... Meistens wir eine Größe verwendet um ein Gefühl für die Größe (wie auch immer du sie messen magst) zu entwickeln.
  • EPIC Business Value. Hier wird der Wert des Scrum EPICs beschrieben. Auch das kann wieder unterschiedlich geschehen. So wäre MuSCoW eine Möglichkeit. Auch T-Shirt Größen können verwendet werden, manche Unternehmen nutzen auch direkte Euros. 

Die Werte kannst du immer diskutieren. Du kannst dir auch Fragen stellen, ob einige der Felder im Sinne einer agilen Entwicklung extra aufgeführt sein müssen. Prüfe auch immer, wie deine Scrum EPICs in der Organisation aussehen müssen und welche Felder du tatsächlich brauchst.

Standardisierung vs. Flexibilität

Gerade wenn es um Beispiele geht, ist die Frage in Unternehmen immer: zeige mir bitte für unseren Fall, das richtige Beispiel. Wie genau geht es? Wie sieht die Vorlage aus? Was sind die Erfahrungen?

Ich sage es gerne so: Lerne von anderen wie ein EPIC in Scrum geschrieben wird, versuche aber nicht zu kopieren. Das EPIC zu standardisieren kannst du nutzen, wenn du zum Beispiel mit dem Scaled Agile Framework arbeitest. Wenn die Ziele von SAFe mit deinen übereinstimmen, dann kannst du einen Blick auf die Beispiele aus SAFe werfen. Doch auch hier: es reicht den Kunden in der Regel eh nie. Es geht immer um genau das Beispiel, was man in der Branche umgesetzt hat. Auch wenn andere Mitspieler oder Konkurrenten in der Branche sind, haben diese meist andere Herausforderungen, Ideen oder Rahmenbedingungen, die es eben nicht möglich machen, zu kopieren.

Du kannst die Gedanken der Agilität nicht standardisieren. In meinen Augen ein klares Oxymon. Aber auch das lassen wir mal eben außen vor. Bei solchen Fragen solltest du dir immer die Frage stellen, was willst du mit der Agilität erreichen? Standardisierung? 

Wie wird ein EPIC umgesetzt?

Du hast nun schon gelernt, dass ein EPIC sehr groß ist, oft keiner formalisierten Notation folgen muss und wie eine User Story geschrieben ist. Das ist für viele meiner Kunden nicht anschlussfähig, da es einfach zu "formlos" ist.

Wieder andere nutzen das EPIC in unterschiedlichen Formen als "Merker" und lassen es im Product Backlog normal reifen, schneiden Stücke ab oder verfeinern es, bis es tatsächlich in einen Sprint passt.

Als Vorgehen für die Umsetzung eines EPICs in Scrum können wir grundsätzlich festhalten, dass wir inkrementell User Stories aus diesem EPIC herunterbrechen. Dazu gibt es die unterschiedlichsten Schneidetechniken. Bedenke auch immer, dass Scrum ein inkrementelles, iteratives Vorgehen ist.

Wie man ein EPIC in Scrum schneiden kann

Wie du schon an der ein oder anderen Darstellung in diesem Artikel erkennst, kann ein EPIC in User Stories zerfallen. Man nutzt den Begriff des EPIC-Schneidens, denn im Grunde geht es immer darum, wie man den Elefanten in kleinere Stücke zerlegen kann. Da diese Schnitttechnik im Grunde nicht anders ist, als bei User Stories oder auch Features, stelle ich hier eine Liste mit Ansatzpunkten zur Verfügung, die du nutzen kannst.

Wenn wir Schnitttechniken für EPICs betrachten, dann ist es immer ein Unterschied, ob du ein Softwaresystem betrachtest oder zum Beispiel physikalische Produkte. Nicht alles kannst du 1:1 übertragen, aber vieles nutzen. Einige Beispiele sind:

  • Nach bestimmten Personas oder Rollen
  • Nach Funktionen oder Fähigkeiten
  • Spikes
  • Regeln
  • Interfaces
  • ...

Abgrenzung des EPICs zu anderen agilen Elementen

Ein EPIC in Scrum hat weitere Beziehungen zu anderen agilen Elementen. Ich möchte diese Elemente nicht Artefakte oder Strukturen nennen, sondern nutze den abstrakten Begriff des Elements. Aus einem EPIC entstehen in der Regel immer User Stories, aber es gibt auch noch ein paar weitere Begriffe, die ich hier ins Spiel bringen möchte.

EPIC zu User Stories zu Wert

User Story

Über die User Story muss ich glaube ich in Scrum nicht viele Worte mehr verlieren. Ein EPIC in Scrum wird wohl in den meisten Fällen einfach in mehrere User Stories aufgehen. 

Thema / Theme

Ein Thema oder Theme wird oft eine eine Sammlung von verschiedenen User Stories verstanden, die thematisch zusammenhängen. Andere Quellen nutzen diese mehr als eine Art von Organisationszielen, was sich auch nicht mit dem vorherigen Satz ausschließen muss - oft aber eine andere Granularität besitzt.

Feature

Mit dem Begriff Feature kann jeder implizit etwas anfangen. Das Feature beschreibt eine Funktionalität für den Kunden (ähnlich zur User Story). Im Scaled Agile Framework befindet sich dieses Element zwischen dem EPIC und der User Story. Im reinen agilen Kontext kennt man den Begriff als Element gar nicht so stark, lässt sich aber je nach Wunsch einarbeiten und unterbringen.

Das EPIC in Jira

Jira behandelt das EPIC in manchen Konfigurationen anders, als wir es aus dem ersten Abschnitt her kennen. In Jira ist das EPIC immer eine Art Klammer, in der mehrere User Stories leben und geführt werden (vgl. Abschnitt Was ist ein Epic). Zwar gibt es  in Jira unterschiedliche Konfigurationen und du kannst viel konfigurieren (wie es zum Beispiel auch Plugins für das Scaled Agile Framework tun), es ist und bleibt aber erst einmal eine Klammer.

Ein EPIC in Jira erstellen

Ein EPIC in Jira zu erstellen ist recht einfach. Das Jira EPIC ist ein Issue Type, wie auch die User Story. Die Darstellung in Jira läuft dabei immer so ab, dass innerhalb eines EPICs mehrere User Stories gruppiert werden und durch eine Beziehung diesem zugeordnet sind.

Folge einfach den folgenden Schritten:

  • Du erstellst dir ein EPIC in Jira in dem du - wie sonst auch - einen neuen Vorgang erstellst. Dazu klickst du auf globalen Navigationsleiste auf "Erstellen" oder "Create"
  • Im nächsten Dialog kannst du dann einfach beim "Vorgangstyp" oder "Issue Type" den EPIC auswählen.
  • Du füllst die gewünschten und verpflichtenden Felder aus
  • Du klickst auf erstellen und dein EPIC beginnt zu leben

Ich kann kein EPIC in Jira erstellen

Solltest du keinen Erfolg mit der Erstellung haben, die ich im vorherigen Abschnitt beschrieben haben, dann können zwei Dinge entscheidend sein, denen du dich widmen solltest

  • Rechte zum Anlegen eines EPICs überprüfen
  • Workflow und Issuetypen überprüfen, ob es überhaupt das EPIC gibt

Das EPIC aus dem Scaled Agile Framework (SAFe)

Grundsätzlich ist ein EPIC aus SAFe schon etwas anderes, als wir vor dem SAFe-Zeitalter verstanden haben. Das Scaled Agile Framework hat dieses nun mehr und mehr formalisiert und kommt mit einer inkrementellen Beschreibung von einem großen Vorhaben um die Ecke (wo wir schon wieder Analogien finden), welches das Hauptmittel ist, um die gemeinschaftliche Ausrichtung eines Portfolios (was wiederum nicht alle unter einem EPIC verstehen) zu steuern.

In SAFe ist das EPIC sehr formal beschrieben und bietet durch mehrere Felder und Informationen, die sich im Ende in einem Lean Business Case vollenden, eine Art von Sicherheit. "Wir haben alle Felder ausgefüllt, die wir benötigen - also muss es ja richtig sein". Das SAFe EPIC wird inkrementell über das Portfolio Board entwickelt.

Der Fluss über ein Kanban Board

Das Scaled Agile Framework nutzt ein einfaches Kanban Board, um den Fluss auf der Portfolio "Ebene". Dieses Board hat bestimmte Kriterien, wann ein EPIC durch verschiedene Schritte des Prozesses laufen darf. 

Du kannst den Ablauf auf dem Kanban Board als ein formalisiertes Refinement verstehen. Was du im Scrum eher als "unauffällige", entwicklungsbegleitende Tätigkeit vorfindest, ist im Scaled Agile Framework für das Portfolio eher ein strengerer Prozess, da hier auch meistens mehrere Personen involviert sind. 

Funnel

Im Funnel entsteht das EPIC, der Lebenszyklus beginnt. Dabei muss in der Regel noch kein bestimmtes Format eingehalten werden. Nichtsdestotrotz gibt es von vielen Unternehmen hier bereits einige Ideen diesen Fluss zu begrenzen, wie

  • strategische Landkarten
  • zugewiesene Landebahnen
  • Begrenzung über Anzahl pro Bereich
  • ...

Zwingend nötig ist das nicht, je mehr Themen natürlich auf dem Portfolio eingehen, kommt gerade bei großen Unternehmen der Wunsch hier auch noch zu limitieren.

Review

Im Schritt des Reviews bekommt das EPIC die erste Klarheit in Form von dem EPIC Hypothesis Statement. Dieser Aufbau kommt vielen auch nicht SAFe-anwendenden Personen recht bekannt vor. Es folgt dabei immer mehr oder weniger dem Aufbau des Elevator Pitches, erweitert um weitere Felder.

Analyse

Schafft es das EPIC in den Schritt der Analyse, dann darf es eine weitere Verfeinerung erfahren, nämlich die des Lean Business Cases. Wichtig dabei ist, dass auch der Lean Business Case kein statisches und finales Dokument ist, welches einmal geschrieben und dann nicht mehr angefasst wird. Es ist ein lebendiges Dokument. Gedacht ist dabei immer an eine inkrementelle Entwicklung, doch dazu später mehr.

Den Prozess auf dem Portfolio Kanban Board kannst du wie einen Reifeprozess und damit auch Refinement verstehen, der auf der Portfolioebene durchgeführt wird. Wir kennen das Refinement natürlich aus Scrum auch, dort ist es allerdings nicht so strukturell und formalisiert durch die Schritte in dem Portfolio Kanban Board. Im Grunde ist es aber nichts anderes.

Sicherheit durch Struktur

Jedes große Unternehmen sucht bei einem Umstieg auf einen agilen Ansatz (wobei oft nur SAFe als agiler Ansatz gesehen wird) meist den Vergleich zur "bisherigen Welt". Das Scaled Agile Framework besitzt daher viele Dinge, die auch sehr kompatibel mit einer "herkömmlichen" Welt sind. So findest du viele formale Angaben und Beschreibungen, die gerade Neueinsteigern ein Gefühl der Sicherheit bieten sollen. In wie weit hier Conways Law, Kultur folgt der Struktur und Veränderungen im Allgemeinen einen Ausschlag geben, lasse ich mal dahin gestellt. Ebenso möchte ich den Ansatz selbst auch gar nicht bewerten.

Das EPIC mit unterschiedlichen Artefakten

Das EPIC ist und bleibt immer ein Artefakt, wird aber durch das EPIC Hypothesis Statement und den Lean Business Case erweitert. Und wenn du es nicht richtig einsetzt, dann ist die Gefahr sehr groß, dass du im Grunde nur eine Spezifikation schreibst und diese dann zu 100% abarbeitest. Hier musst du aufpassen, weil genau das nicht das Ziel ist (weder vom EPIC noch von SAFe).

EPIC Hyothese

Die meisten "Agilisten" kennen von früher auch noch die Form einer Beschreibung in der Form, wie es das Scaled Agile Framework für die EPIC Hypothese vorsieht. Es ist nämlich eine mehr oder weniger lang bekannte Form des Elevator Pitches. Ich habe zwar keine genaue Quelle mehr finden können, meine aber mich dunkel zu erinnern, dass ich das schon seit gefühlten 15 Jahren kenne.

<An elevator pitch (value statement) that describes the epic in a clear and concise way.>

For <customers>
who <do something>
the <solution>
is a <something – the ‘how’>
that <provides this value>
unlike <competitor, current solution or non-existing solution>
our solution <does something better — the ‘why’>

Quelle: Scaled Agile Framework, https://www.scaledagileframework.com/epic/

Zudem hat das Scaled Agile Framework dem EPIC nun noch etwas mehr dazu gegeben, nämlich folgende Felder:

Customers served! 1 Felder im Hypothesis Statement
  • Funnel Entry Date
  • EPIC Name
  • EPIC Owner
  • Business Outcomes
  • Leading Indicators
  • Nonfunctional Requirements

Funnel Entry Date

Das Feld Funnel Entry Date ist selbsterklärend. Hier wird das Datum festgehalten, wenn das EPIC auf dem Portfolio Board seinen Lebenszyklus startet. Da dieses ein Kanban Board ist, kann mit diesem Datum unterschiedliche Dinge gemessen, wie zum Beispiel eine Durchlaufzeit.

EPIC Name

Für das EPIC wird eine Name oder auch Titel festgelegt. Hier versuchst du kurz und prägnant einen Titel zu finden, der das EPIC schnell erkennen lässt. So etwas darf sich natürlich auch über den Lebenszyklus ändern.

EPIC Owner

Der EPIC Owner im Scaled Agile Framework ist jemand, der sich um dieses EPIC während des Lebenszyklus kümmert und inhaltlich vertreten kann. Achte darauf: wenn du hier einfach Projektleiter einsetzt und das EPIC auch noch als 100% Spezifikation betrachtest, dann kannst du es auch gleich lassen 😉 Schaue dazu gerne in meine Dysfunktionen weiter unter noch mal genauer rein.

Business Outcomes

Hier formulierst du den erwarteten Outcome, nicht Output (ich habe einen Artikel Outcome vs. Output für die Unterschiede geschrieben). SAFe sieht es als messbaren Nutzen, den ein Unternehmen erwarten kann.

Leading Indicators

An welchen Indikatoren kannst du festmachen, dass deine Hypothese untermauert wird? Das können ganz unterschiedliche Dinge sein, die sich früh erkennen lassen, ob es in die richtige Richtung geht. Sowas kann im einfachsten Fall ein Feedback sein, weniger LoC oder auch bestimmte erlebbare Dinge.

Nonfunctional Requirements

Hier hältst du in deinem SAFe EPIC fest, welche nicht funktionalen Anforderungen hier relevant sind. Das sind oft Skalierbarkeit, Wartung, Performance und ähnliche Dinge.

Zusammenfassung

Diese EPIC Hypothese kann man in der Tat sehr schnell schreiben. Ich habe auch mit Kollegen bei Kunden das ein oder andere Mal eine EPIC Hypothese "kalt" geschrieben. Sprich, mit einigen Informationen (ohne Experte zu sein) kann man sich dieser Hypothese sehr gut nähern. Natürlich wissen es die Menschen in der Organisation besser. Sie können es schreiben, die kennen die Sprache der Stakeholder und das ist dann natürlich zielführender - klar. Es zeigt aber einen Punkt sehr schön: Den ersten Entwurf für eine EPIC Hypothese liegt eben nicht in Tagen oder Wochen, sondern Stunden (eine erste Version).

Das zeigt aus meiner Sicht einen Aspekt sehr schön: inkrementell das SAFe EPIC erweitern und keine Spezifikationen schreiben. Wir investieren hier erstmal wenig Arbeit in die Erstellung eines Artefaktes. Rutsch das EPIC dann im Prozess weiter, investieren wir mehr Arbeit.

EPIC Lean Business Case

Der Lean Business Case im Scaled Agile Framework ist in der Regel in großen Unternehmen sofort anschlussfähig, je kleiner und agiler ein Team bereits ist, desto mehr Skepsis ernte ich in der Regel. Aber bleiben wir mal gerade bei den Unternehmen, für die es anschlussfähig ist. Der Lean Business Case ist nach SAFe eine weitere Verfeinerung des SAFe EPICs. Schauen wir uns hier die einzelnen Feldern einmal genauer an.

Übersicht über die Felder des Lean Business Case

Customers served! 1 Felder im Lean Busines Case
  • Funnel Entry Date
  • EPIC Owner
  • Key Stakeholder
  • EPIC Description
  • Business Outcome Hypothesis
  • Leading Indicators
  • In Scope
  • Out of Scope
  • Non Functional Requirements
  • Minimum Viable Product (MVP) Features
  • Additional Potential Features
  • Analysis Summary
  • Go / No-Go
  • Which Internal and/or external customers are affected, and how?
  • What is the potential impact on solutions, programs and services?
  • What is the potential impact on sales, distribution, deployment and support?
  • MVP Cost
  • Estimated Implementation Cost
  • Type of Return
  • In-house or Outsourced Development
  • Incremental Implementation Strategy
  • Sequencing and Dependencies
  • Attachments
  • Other Notes and Comments

Quelle: Scaled Agile Framework, https://www.scaledagileframework.com/epic/

Und, was fällt auf? Genau, ziemlich viele was? 🙂 Du findest einige Felder, die dir schon aus dem Hypothesis Statement bekannt vorkommen sollten. Auch hier gilt, es entwickelt sich inkrementell weiter. Sprich du findest entweder die gleichen Felder erneut oder in angepasster Variante.

Ich möchte jetzt gar nicht auf jedes Feld eingehen, schon gar nicht auf die, die wir im EPIC Hypothesis Statement schon besprochen haben. Einige besondere Felder habe ich mir dennoch raus gepickt, zu denen ich dir gerne noch meine Sicht mit auf den Weg geben möchte, damit auch dein SAFe EPIC gut werden kann.

In Scope & Out of Scope

Dieses Denken gefällt mir persönlich sehr gut. Dazu gibt es auch eine Brainstorm Technik mit "Ist / Ist nicht" und persönlich finde das gut zur Entwicklung eines gemeinsamen Verständnis, was as Abgrenzung überhaupt relevant ist.

Aus meiner Erfahrung lässt sich so eine Diskussion recht gut starten. Das wissen Menschen oft recht schnell. Dann muss man die Flughöhe natürlich etwas anpassen und ein paar mal nachfragen.

Minimum Viable Product (MVP) Features

Bei diesem Feld gibt es die meistens Diskussionen, die oft im Verständnis vom MVP begründet sind. Es hilft kommend vom In Scope die ersten Schritte Richtung Umsetzung zu definieren. Es hilft noch mal zu reflektieren: Was brauchen wir wirklich?

Den meisten Unternehmen hilft es auch dabei etwas mehr in das Verständnis zu investieren: Der Begriff des MVP ist oft nicht verstanden, (noch) nicht möglich und führt zu unnötigen Diskussionen.

Ein Beispiel: Mir persönlich liegt der MVP Begriff sehr, ich habe immer gedacht, dass muss doch für jeden verständlich sein. Egal ob es um ein SAFe EPIC geht oder noch im reinen Lean Start-Up Gedanke. Doch dem ist nicht so, muss nicht so sein und ich muss mit den Menschen in die Diskussion gehen, wo sie stehen und wo Sichtweisen sind.

Additional Potential Features

Wenn wir uns Gedanken gemacht, was in einer Minimalstufe umgesetzt werden kann, dann macht es auch Sinn weitere zusätzliche Features festzuhalten. Und das nicht um Verschwendung zu erzeugen, sondern klar zu machen und abzugrenzen, was in eine minimale Version rein gehört. Hier kannst du in deinem SAFe EPIC dann alles parken, was du noch nicht direkt im VMP umsetzen möchtest.

MVP Cost & Estimated Implementation Cost

Für viele wichtig, oft in meinen Augen unterschiedlich geht es bei diesen beiden Feldern um die Kosten. Während ich die MVP Kosten noch häufiger finden, sind die gesamten Kosten eher weniger oft anzutreffen. Nicht, weil man es nicht will, sondern weil man es oft wenig bis gar nicht weiß.

Dazu finde ich dann öfters eine Anpassung der MVP Kosten, die sich dann auf das (was es faktisch nicht gibt) nächste MVP beziehen. Hier findet dann eine Anpassung über diese Art statt, dass das Feld für die MVP Feature und die MVP Kosten sich laufend aktualisieren, jedenfalls über die PI's hinweg.

Oft sind Kunden auch noch gar nicht in der Lage so die Kosten pro SAFe EPIC zu bestimmen, sondern gehen eher "klassische" Wege der Finanzierung des Portfolios.

Incremental Implementation Strategy

Wenn wir wirklich von großen Unternehmen sprechen, die erste Schritte machen, dann finden wir mit diesem Feld eine Hilfe, die ich grundsätzlich keinem direkt als Agilität empfehlen würde, die aber die Brücke baut wenn wir noch zu wenig agile Praktiken haben, um zum Beispiel richtig gute Inkremente zu bauen.

Ein zweiter Punkt ist oft die Klarheit durch Architektur und Portfolio einen abgestimmten, gemeinschaftlichen Weg zu gehen.

Stell dir einen Fall vor, in dem eine Architektur modernisiert wird oder ähnliche größere Blöcke, die zum Beispiel (noch) keinen Mehrwert von kleinen Teilen ergeben können, sondern nur in Summe. Klar, das riecht nach Wasserfall und ist es auch oft, hilft aber als "Modell für eine ordentliche Zusammenarbeit" (Danke an Joachim für diesen Ausdruck, den ich bin heute noch gerne für SAFe verwende 😉 oft durchaus weiter.

So könnte eine inkrementelle Entwicklungsstrategie durchaus ein Spike sein, der als erstes durchgeführt werden soll und mögliche Optionen, die resultieren können, um weitere Schritte abzuleiten. Für mich ist das Feld auch nicht immer richtig oder falsch zu befüllen, sondern sollte durch eine gute und zielgerichtet Kommunikation erfolgen.

Sequencing and Dependencies

Hier haben die Unternehmen die Möglichkeit Abhängigkeiten und Abfolgen im Bezug auf dieses EPIC zu beschreiben. Jetzt ist ein EPIC ja schon groß und soll noch Abhängigkeiten haben? Ich persönlich merke da immer: Je mehr man eine klassische Brille aufsetzt und die EPICs zu schreibt ist das der Fall. 

Ein gutes EPIC in SAFe schreiben

Wenn du ein gutes SAFe EPIC schreiben möchtest, bist du hier genau richtig. Ich nehme bewusst das Scaled Agile Framework, da dieses eine Struktur bietet die beschrieben ist, die du gut diskutieren kannst. 

Das EPIC entsteht auf der Portfolio Ebene und hat seinen Lebenszyklus bis es durch eine Bewertung mittels der WSJF Bewertung als nicht mehr wirtschaftlich angesehen wird oder die Hypothese als bewiesen gilt.

Wie schreibe ich ein EPIC Hypothesis Statement?

Konkret mache ich es persönlich gerne so, dass ich im digitalen Zeitalter ein digitales Whiteboard nutze, in der analogen Welt einen möglichst großen Ausdruck, den ich an die Wand hängen und ggf. so mit mehreren diskutieren kann.

Inhaltlich gehe ich mit einem Brainstorming an die Sache heran. Ich persönlich muss immer viel aufschreiben, sehen, überdenken und dann finalisieren. Dazu nehme ich einfach Zettel und schreibe raus, was mir einfällt. Das klappt analog, wie digital in meinen Augen recht gut.

Über die einen oder anderen Felder stolpere ich natürlich selbst immer und immer wieder. Und das geht auch Kunden nicht anders. Es ist ab und an eben knifflig. Manche Felder sind schwerer, andere leichter. Das ist wenig überraschend und natürlich nicht nur hier so. Wenn wir Denkleistungen bringen müssen, dann kann das einige (Um-)Wege mit sich bringen.

Hier hilft es aus meiner Sicht, immer direkt in die Kommunikation zu gehen. Bei einem EPIC hast du die Möglichkeit einfach mal andere Epic Owner zu fragen oder auch direkt mit den Kunden und Stakeholdern in die Diskussion zu gehen.

Wenn du Probleme hast, ein EPIC zu schreiben kann es der Fall sein, dass du gar kein EPIC schreiben solltest. Du hast keine Hypothese? Du kannst kein Elevator Pitch schreiben? Nicht alles in einem Unternehmen muss über ein EPIC umgesetzt werden. Dazu tendieren aber viele Unternehmen. Wenn das bei dir der Fall ist, schaue dir bitte die Grundlagen noch einmal genauer vom SAFe an.

Über diese erste Version iteriere ich dann, bis ich als "Akzeptanzkriterium" des Schrittes Review alles getan habe, was in diesem Schritt notwendig ist. Akzeptanzkriterien könnten zum Beispiel lauten:

  • Alle Felder des EPIC Hypothesis Statements sind ausgefüllt
  • Ein 4-Augen-Review hat stattgefunden
  • ...

Den Lean Business Case schreiben

Den Lean Business Case zu schreiben ist praktisch genau zu tun, wie auch das EPIC Hypothesis Statement. Es ist eine inkrementelle Arbeitsweise. Methodisch helfen auch hier die oben genannten Arbeitsweisen.

Ein EPIC Owner wird mehr in die Abstimmung gehen, das Refinement hilft auch de nötigen Rahmen zu geben und die Akzepatanzkriterien geben dir Leitplanken einen guten Lean Business Case zu schreiben.

Nicht jeder Kunde schreibt ein EPIC Hypothesis Statement. Ich habe auch Unternehmen erleben können, die zum Beispiel gleich mit dem Lean Business Case beginnen und dort pro Schritt (Review, Analyse, ...) unterschiedliche Felder ausgefüllt haben.

Achte unbedingt darauf, dass du nicht in endlose Diskussionen abschweifst. Du solltest in Refinements auch wirklich über den Inhalt sprechen. EPICs die nur angeschaut werden, füllen sich nicht von alleine. Dabei hilft den Unternehmen meistens ein klarer Ablauf in solchen Terminen und gute Moderation. Dinge, die du nicht direkt lösen kannst, solltest du zeitnah klären und nicht alle (nicht betroffenen) Menschen involvieren.

Dysfunktionen von SAFe EPICs

Wie so immer gilt auch beim SAFe EPIC und dem Scaled Agile Framework in Summe: man kann es auch so anwenden, dass das EPIC schreiben keinen Spaß macht und absolut am Ziel vorbei geht. Einige Beispiele, die ich schon öfters gesehen habe möchte ich dir im Folgenden mitgeben. Schaue dir diese Beispiele bitte an und reflektiere bei dir im Unternehmen!

Da gerade das Scaled Agile Framework eine ziemlich konkrete und formalisierte Form der Beschreibung anbietet, lassen sich konkrete Dysfunktionen von EPICs natürlich auch sehr leicht finden und reflektieren. 

EPIC wird durch Projekt ersetzt

Ein EPIC ist kein Projekt. Wer den EPIC Owner als Projektleiter einsetzt, das EPIC als einmaliges Anlegen und 100% Umsetzung mit fixen Umfang versteht, der hat nichts gewonnen. So wird es keinen Spaß machen und dir auch im Unternehmen recht wenig bringen. 

Ein SAFe EPIC hat keine zeitliche Komponente. Das ist wichtig und zeigt auch hier, dass es keinen Projektcharakter auf der Portfolioebene gibt - viele bauen diesen aber wieder in den Prozess mit rein. Das ist aber nicht Sinn und Zweck eines SAFe EPICs. Die wichtigste Planungsgröße ist im Scaled Agile Framework immer das Feature. Nie das EPIC, denn im Grunde hat es keine zeitliche Komponente.

Das Refinement auf Portfolioebene falsch verstehen

Auf der Portfolio Ebene findet grundsätzlich immer ein Refinement statt. Dieses Refinement muss von Menschen durchgeführt werden, die auch in der Lage sind, EPICs zu refinenen.

Alles über das Portfolio

Häufig ist es so, dass Unternehmen implizit annehmen, dass aller Eingang von Arbeit über ein Portfolio stattfinden muss. Das ist ganz klar eine Falschannahme. Ein EPIC ist nicht ein reines Strukturelement, sondern hat einige weitere wichtige Eigenschaften, die es zu einem EPIC erst machen. So kann es genauso auch die Arbeit geben, die nur als Feature ins System gelangt, ebenso wie User Stories.

Portfolio als Hierarchie verstehen

Das Portfolio ist keine Hierarchie und auch die Rollen haben keine hierarchische Wirkung auf die anderen Ebenen oder Rollen. Wir fokussieren auch einen Wertstrom, der gerade im Portfolio strategische und finanzielle Aspekte adressiert.

Wir werden langsamer, statt schneller?!

Durch "alles über das Portfolio" und "alles wird durch die Hierarchie getrieben" folgt oft: wir werden langsamer. Das ist natürlich für die Unternehmen erschreckend, resultiert aus meiner Perspektive aber durch die falsche Anwendung bzw. am "herumschrauben" am Framework selbst. Hier musst du unbedingt immer an die folgenden Aspekte denken:

  • Entscheidungen müssen dort getroffen werden, wo auch die Informationen dazu liegen. Das kann die Dezantralisierung oder auch Zentralisierung von Entscheidungen bedeuten, aber eben nicht alles an einer Stelle für alles.
  • Transparenz von Arbeit schaffen und diese auch gewissenhaft ans Tageslicht bringen. 
  • Limitierung der Arbeit, denn sonst werden Unternehmen niemals schneller sondern immer nur langsamer.

Alles ist zusammenhängend

Ein EPIC, ein Feature und eine User Story bilden natürlich eine hierarchische Struktur. Eine Fehlannahme ist hier, eine User Story muss an einem Feature hängen und das wiederum zwangsläufig an einem EPIC. Das machen viele Unternehmen schon gerne und vertsehen dabei oft eine Reporting-Sicht.

Die Angaben im EPIC nicht auf das MVP beziehen

Ein gern gemachter Fehler ist die Angaben im Lean Business Case nicht auf das MVP zu beziehen. Wenn ich schätze, dann schätze ich nicht das gesamte EPIC etwa (vergleiche 100% Spezifikation), sondern ich versuche das MVP zu schätzen.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>