4 Min. Lesezeit
Epics sind Wetten
Outcome-Hypothesen, MVPs und die Erlaubnis aufzuhören
Teil vier der Werkzeugkiste des Product Owners. Das Ferientool hat jetzt eine Vision. Als Nächstes kommt das erste grosse Stück Arbeit.
Ein Epic beschreibt ein grosses Bedürfnis oder Problem: so gross, dass seine Lösung eine echte Investition ist, oft so gross, dass es einen schlanken Business Case braucht. Es ist die grösste Art von Backlog-Eintrag und sollte leicht verständlich sein. Es sagt grob, warum etwas gelöst werden soll und was, mehr nicht.
Die meisten Backlogs behandeln Epics wie Ordner, als Sammelort für Stories, die zusammengehören. Damit verpasst man, wofür ein Epic da ist. Ein Epic ist eine Wette: Wir glauben, dass so viel Aufwand so viel bringt. Es lohnt sich, es auch so zu behandeln.
Die Wette aufschreiben
Jedes Epic braucht einen klaren Umfang und eine Outcome-Hypothese, dazu harte Messgrössen, die zeigen, ob der Wert tatsächlich eingetroffen ist. Ich nutze dafür eine einseitige Vorlage:
| Feld | Inhalt |
|---|---|
| Titel | Der Name des Epics |
| Wichtigste Stakeholder | Wem es wichtig ist, mit Namen |
| Beschreibung | Der Elevator Pitch |
| Nutzen | Der Mehrwert für Nutzer und Geschäft |
| Outcome-Hypothese | Was sich unserer Erwartung nach ändert |
| Messgrössen | Die Zahlen, die die Hypothese bestätigen oder verwerfen |
| MVP-Features | Der kleinste Umfang, der die Hypothese testet |
| Nicht-funktionale Anforderungen | Was in jedem Fall gelten muss (Verfügbarkeit, Sicherheit, Datenstandort) |
Für das Ferientool:
- Titel: Ferien online beantragen und bewilligen
- Beschreibung: Mitarbeitende beantragen Ferien im Tool, Teamleitende bewilligen sie dort, und HR sieht das Ergebnis, ohne etwas abzutippen.
- Nutzen: HR pflegt keine Tabelle mehr. Mitarbeitende kennen ihr Guthaben. Teamleitende sehen Konflikte, bevor sie bewilligen.
- Outcome-Hypothese: Innerhalb eines Quartals braucht HR 80 % weniger Zeit für die Ferienadministration.
- Messgrössen: Stunden pro Monat, die HR für Ferien aufwendet, gemessen vorher und nachher. Anteil der Anträge, die im Tool statt per E-Mail bewilligt werden.
- MVP-Features: Antrag stellen, bewilligen oder ablehnen, Teamkalender anzeigen.
- Nicht-funktional: Funktioniert im Browser auf dem Handy. Die Daten bleiben in der Schweiz.
Das MVP ist nicht Version eins
Ein Minimum Viable Product ist die einfachste Version des Produkts, mit der das Team seine Annahmen testen kann. Eric Ries hat den Kreislauf in The Lean Startup beschrieben: etwas Kleines bauen, messen, wie echte Nutzer darauf reagieren, daraus lernen und das Gelernte ins Produkt zurückspielen.
Seine Hauptaufgabe ist, Risiken zu senken. Vielleicht weisst du noch zu wenig über das Problem der Nutzer, oder du weisst nicht, ob die technische Lösung funktioniert. So oder so macht das MVP aus Annahmen Wissen, und dieses Wissen fliesst zurück ins Produkt.
Was ein MVP nicht ist: die erste kommerziell nutzbare Version. Deshalb lässt es sich schlecht am Return on Investment messen. Du bezahlst für das, was du lernst.
Nimm also das Günstigste, das dir etwas beibringt: einen Papierprototyp, ein klickbares Mockup, ein paar Zeilen Code. Jede Form ist recht, solange sie echtes Feedback zur Hypothese liefert. Danach wirfst du es weg oder baust die nächste Iteration darauf auf.
Beim Ferientool ist die riskanteste Annahme nicht technisch. Sie lautet: Teamleitende bewilligen Anträge in einem Tool, statt auf eine E-Mail zu antworten. Wenn sie das nicht tun, ist alles andere egal. Der günstigste Test ist ein einfaches Formular, das der Teamleiterin einen Link mit zwei Knöpfen schickt, vier Wochen lang in einer Abteilung. Dann zählst du, wie viele Bewilligungen über den Link kommen und wie viele immer noch per E-Mail.
Die Wetten zeigen
Epics werden am Anfang mit den Stakeholdern gesammelt, aber die Liste bleibt nicht gleich. Strategische Entscheide und Feedback von Nutzern bringen neue Epics, verändern bestehende und streichen andere.
Stell die Epics auf ein eigenes Kanban-Board. So sieht jeder den Fortschritt, und du kannst Cycle Time und Lead Time im Auge behalten. Ein Epic, das neun Monate in «In Arbeit» steht, will dir etwas sagen.
Brich Epics erst dann in Features und Stories herunter, wenn die Arbeit daran gleich beginnt, wie in Just in Time spezifizieren beschrieben.
Die Erlaubnis aufzuhören
Diesen Teil lassen die meisten Organisationen aus. Zu einem Epic gehören sein MVP und der Business Value, den das MVP belegen soll. Zeigt sich der Wert nach dem MVP nicht, stoppst du das Epic. Zeigt er sich, baust du den Rest.
Aufhören ist das Ergebnis, das am meisten Geld spart, und das, was sich am schwersten verkaufen lässt. Schreib die Abbruchbedingung auf, bevor du anfängst, solange noch niemand etwas investiert hat und niemandes Stolz auf dem Spiel steht.
Als Nächstes
Bevor wir das Epic in Features herunterbrechen, müssen wir wissen, für wen wir bauen. Nächstes Mal: Personas und User Journeys, und warum eine Persona ohne Recherche ein Klischee mit Namen ist.