Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.
Was genau ist ein Epic?#
Ein Epic ist ein grosses Arbeitspaket, das in kleinere Teile heruntergebrochen werden muss. Ein oder mehrere Teams arbeiten an einem Epic, und jedes Epic hat einen Titel, einen Owner und eine Beschreibung. Die Grösse eines Epics sollte zwischen drei und neun Monaten liegen, weil wir die Hypothese dahinter so schnell wie möglich evaluieren und Wert an den Markt liefern wollen.
Der Schlüssel zum Epic ist das Epic Hypothesis Statement. Das ist nicht einfach eine Beschreibung dessen, was gebaut werden soll. Es ist ein strukturierter Pitch, der alles klar macht: Für welchen Kunden, der was möchte, ist unsere Lösung etwas, das einen bestimmten Wert liefert, und im Gegensatz zum Wettbewerb macht unsere Lösung es besser. Mit einer solchen Beschreibung wird klar, wofür das Epic da ist, welchen Kunden wir bedienen und warum.
Noch wichtiger: Wir müssen messbare Geschäftsergebnisse und Leading Indicators definieren. Das sind keine nachlaufenden Indikatoren, die uns erst im Nachhinein informieren. Leading Indicators sagen uns so früh wie möglich, schon während der MVP-Entwicklung, ob unsere Hypothese wahr oder falsch ist.
Der Lebenszyklus eines Epics#
Der Lebenszyklus funktioniert so: Eine gute Idee kommt vom Business oder von Kunden. Wir erfassen sie im Epic Hypothesis Statement und legen sie auf das Product Backlog. Wenn genügend Kapazität vorhanden ist, bauen wir ein Minimum Viable Product (MVP). Das ist das Minimum, das wir bauen müssen, um die Hypothese zu beweisen oder zu widerlegen.
Dann evaluieren wir die Hypothese anhand der Leading Indicators und Geschäftsergebnisse. Wenn die Hypothese stimmt, entwickeln wir weitere Features und re-evaluieren. Wenn die Hypothese widerlegt wird, entscheiden wir: Machen wir einen Pivot mit einem neuen, angepassten Epic, oder hören wir ganz auf? Dieses Modell wird auch von vielen erfolgreichen Startups verwendet.
Ein konkretes Beispiel: Swiss Dentist#
Hier ein fiktives Beispiel. “Swiss Dentist” ist ein Unternehmen mit Praxen in allen grossen Schweizer Städten. Der CEO, Dr. Hans Muster, hat eine Idee: eine mobile App, über die Kunden Zahnarzttermine vereinbaren und verwalten können.
Das Epic Hypothesis Statement sieht so aus:
Epic Name: Mobile App für Zahnarzttermine Epic Owner: Dr. Hans Muster Beschreibung: Für Swiss-Dentist-Kunden, die einen Zahnarzttermin vereinbaren möchten, ist die Swiss Dentist App eine mobile Anwendung, die das Buchen, Umbuchen und die Standortsuche ermöglicht. Im Gegensatz zu AAA-Dentist (dem Wettbewerber) hält unsere Lösung die Kunden durch automatische Benachrichtigungen auf dem Laufenden.
Die Geschäftsergebnisse: Die Mehrheit der Termine wird über die App gebucht, das Callcenter-Volumen sinkt und die Kundenzufriedenheit steigt. Die Leading Indicators: weniger Callcenter-Aktivität bei der Terminbuchung und eine Zunahme der Gesamttermine durch automatische Benachrichtigungen.
Die Kraft des Pivots#
Jetzt wird es spannend. Als MVP wählten wir einen Papier-Prototypen. Wir gingen zu echten Kunden und fragten: Würden Sie diese App herunterladen und nutzen? Die Mehrheit sagte: “Nicht schon wieder eine App! Ich habe zu viele davon. Aber wenn es eine Webanwendung wäre, würde ich sie gerne nutzen.”
Die Hypothese wurde widerlegt. Aber wir haben keine Monate an Entwicklungszeit verloren. Wir machten einen Pivot, erstellten ein neues Epic für eine Webanwendung und durchliefen den Zyklus erneut. Nach Bau und Rollout des Web-MVPs zeigten die Daten klare Verbesserungen: Das Callcenter-Volumen sank, die über das Web gebuchten Termine stiegen, und die Gesamtanzahl der Termine wuchs. All das war schon früh, während der MVP-Phase, sichtbar.
Das ist der grosse Vorteil von Epics: Man kann eine Idee sehr früh evaluieren und fundierte Entscheidungen treffen, bevor man stark investiert.
Projekt vs. Epic#
Der Vergleich ist deutlich:
- Scope: Projekte haben einen fixen Scope mit einer Liste von Deliverables. Epics haben einen variablen Scope, definiert durch Geschäftsergebnisse und Leading Indicators.
- Messung: Projekte messen Output (gelieferte Features). Epics messen Outcome (Hypothese bewiesen oder widerlegt).
- Zeitrahmen: Projekte haben fixe Start- und Enddaten. Epics laufen, bis die Hypothese validiert und die Geschäftsergebnisse erreicht sind.
- Umsetzung: Projekte nutzen typischerweise Waterfall oder “Water-Scrum-Fall.” Epics nutzen agile Methoden.
- Teams: Projekte haben temporäre, zusammengestellte Teams. Epics haben stabile, crossfunktionale Teams, die am Backlog arbeiten.
- Budget: Projekte haben fixe Budgets. Epics nutzen Finanzierung über Value Streams.
- Betrieb: Projekte werfen Ergebnisse über die Mauer zum Betrieb. Epics umfassen den gesamten Betriebszyklus.
Warum wir Epics nutzen sollten#
Was in Organisationen üblicherweise passiert: Wir haben viele tolle Ideen und wollen alle umsetzen. Aber wir vergessen, dass wir die Entwicklungsteams damit komplett überlasten. Manche Ideen sind grossartig, andere sollten nie entwickelt werden. Das Ergebnis: Technical Debt häuft sich an, die Qualität sinkt, und die wirklich guten Ideen bekommen nicht die Aufmerksamkeit, die sie verdienen.
Mit Epics bringen wir Disziplin ein. Wir erstellen das Hypothesis Statement, definieren Geschäftsergebnisse, identifizieren Leading Indicators, bauen ein MVP und evaluieren schnell. Wenn die Hypothese scheitert, machen wir einen Pivot oder stoppen. Wenn sie bestätigt wird, entwickeln wir weiter und re-evaluieren. So können sich die Entwicklungsteams auf die richtigen Features konzentrieren und das Richtige auf die richtige Art bauen.
Kernaussagen#
- Epics sind hypothesengetrieben. Jedes Epic beginnt mit einem klaren Hypothesis Statement, das Kunden, Lösung, Wert und Wettbewerbsvorteil definiert.
- Leading Indicators sind essenziell. Sie ermöglichen es, eine Hypothese so früh wie möglich zu validieren oder zu widerlegen, nicht erst nach Monaten der Entwicklung.
- Zuerst ein MVP bauen. Das Minimum Viable Product ist der schnellste Weg zu lernen, ob eine Idee Potenzial hat.
- Pivot oder Stopp ohne schlechtes Gewissen. Eine früh widerlegte Hypothese spart Zeit, Geld und Teamkapazität für die Ideen, die wirklich zählen.
- Epics schlagen Projekte. Durch den Fokus auf Outcomes statt Outputs verhindern Epics die Überlastung von Teams und stellen sicher, dass das Richtige richtig gebaut wird.