Das Aufsplitten von Epics

Ein Scrum Trainer fragte mich kürzlich nach ein paar guten Beispielen, bei denen große User Stories (Epics) in kleinere Stories aufgeteilt wurden. Diese Beispiele möchte ich mit Ihnen teilen.

Epic 1: Die richtige Marketingkampagne finden

Das erste Beispiel handelt von einer Firma, die Software an große Einzelhandelsunternehmen verkauft (WalMart etc.). Der Leiter der Marketingabteilung musste entscheiden, wie der Werbeetat ausgegeben werden sollte. Daher wurde die User Story (Epic) aus seiner Sicht geschrieben. Sein erstes großes Ziel war:

Als Leiter der Marketingabteilung möchte ich die bisherigen Werbekampagnen einsehen können, damit ich lukrative Kampagnen identifizieren und wiederholen kann.

Die Teammitglieder sagten, dies sei ganz klar ein Epic. Also bat ich sie, daraus mehrere kleinere Stories zu machen:
1a: Als Leiter der Marketingabteilung möchte ich eine Zeitspanne auswählen können, aus der die zu überprüfenden Werbekampagnen stammen, damit…
2a: Als Leiter der Marketingabteilung möchte ich aussuchen können, welche Kampagnen (Postwurfsendungen, TV, E-Mail, Radio usw.) in die Überprüfung einbezogen werden sollen, damit….

(Beachten Sie, dass ich die Stories so nummeriert habe, dass man erkennen kann, von welcher ursprünglichen Story sie abstammen. In einem echten Projekt würde ich das nicht notwendigerweise tun – außer ich hätte ein Tool, bei dem das automatisch geschieht.)

Ich wusste nicht genau, wie groß diese beiden Stories waren und ob man sie noch einmal aufsplitten sollte. Also fragte ich das Team: “Wenn ihr diese Stories einschätzen müsstet, welche Einheit käme euch als erstes in den Sinn? Stunden, Tage, Wochen, Monate oder Jahre?” Bei 1a waren es Tage, also blieb die Story, wie sie war. Bei 1b waren es Wochen und darum unterteilten wir die Story noch einmal:

• 1b1: Als Leiter der Marketingabteilung möchte ich Informationen zu Postwurfsendungen früherer Kampagnen einsehen können, damit…

• 1b2: Als Leiter der Marketingabteilung möchte ich Informationen zu TV Werbung früherer Kampagnen einsehen können, damit…

• 1b3: Als Leiter der Marketingabteilung möchte ich Informationen früherer Kampagnen  mit E-Mail Werbung einsehen können, damit…

• usw.

Jede dieser Stories hatte eine gute Größe (“wir würden diese Story in Tagen einschätzen”). Jedoch benötigten sie noch gewisse Informationen – die sogenannten “Conditions of Satisfaction”, welche im Grunde genommen High-Level Akzeptanztests sind. Für 1b2 schrieben die Teammitglieder Folgendes auf die Rückseite der Karteikarte:

• Wie viele Zuschauer aus welcher Altersklasse gab es?

• Wie viele Zuschauer aus welcher Einkommensklasse gab es?

Beispiel 2: Umsatzmaximierung eines Hotels

In diesem Beispiel geht es um ein Hotel, bei dem der Umsatz maximiert werden sollte, d.h. der Betreiber wollte den höchstmöglichen Preis für die Hotelzimmer finden. Die Preise wurden anhand einiger Faktoren berechnet. Das waren beispielsweise Zimmerpreise vergleichbarer Hotels, die Jahreszeit, Großveranstaltungen in der näheren Umgebung (wenn der Super Bowl oder eine Weltmeisterschaft in einer Stadt ausgerichtet wird, steigen dort die Preise) usw.

Dies war die ursprüngliche User Story (Epic):

1: Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer finden.
Der Einfachheit halber gehen wir einfach davon aus, dass das Hotel nur über eine Kategorie an Zimmern verfügt. Wie bereits erwähnt, können viele Faktoren den Preis für ein Hotelzimmer beeinflussen. Die grundlegende Formel für die Berechnung des Zimmerpreises sieht dann folgendermaßen aus:

Zimmerpreis = f (a,b,c…)

Diese Funktion unterliegt verschiedenen Faktoren. Für jeden einzelnen davon gibt es eine Story:
1a: Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer anhand der Preise des letzten Jahres festlegen.
1b: Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer anhand der Preise vergleichbarer Hotels festlegen.

Story 1a besagt nur, dass die Preise vom Vorjahr in der Funktion berücksichtigt werden. Story 1b besagt, dass auch die Preise, die andere Hotels verlangen, in die Kalkulation einbezogen werden.

Jede der Stories war relativ groß (ein Epic) und natürlich es gab mehr als die zwei oben genannten Stories. Daher wäre es unmöglich gewesen, alle in einen einzigen Sprint zu legen. Die Stories wurden nach und nach umgesetzt und so kam bei der besagten Formel ein falscher Preis heraus, da sie folgendermaßen aufgebaut wurde:

Zimmerpreis = f (a)

dann

Zimmerpreis = f (a,b)

dann

Zimmerpreis = f (a,b,c)

usw.

Nach dem ersten Sprint wäre die Berechnung also Zimmerpreis = f (a) und man bekäme einen falschen Preis (der nicht an den Kunden weitergegeben werden kann). Die Berechnung an sich ist aber grundsätzlich korrekt. Vielleicht sind die Werte für (b) und (c) hart codiert oder werden einfach nur ignoriert. Aber auf diese Art und Weise können solche komplexen Algorithmen inkrementell aufgebaut werden.

Weil Story 1b immer noch zu groß war, wurde sie erneut unterteilt:

• 1b1: Als Hotelier kann ich eine gewisse Anzahl vergleichbarer Hotels festlegen. (Dafür wurde der Begriff “Comparable Set” in diesem Unternehmen verwendet.)
• 1b2: Als Hotelier kann ich Hotels zu dem Comparable Set hinzufügen.
• 1b3: Als Hotelier kann ich Hotels aus dem Comparable Set entfernen.
• 1b4: Als Hotelier kann ich ein komplettes Comparable Set löschen, das ich nicht mehr benötige.
• 1b5: Als Hotelier orientiere ich mich an den Zimmerpreisen der Hotels in einem bestimmten Comparable Set, um meine Zimmerpreise zu bestimmen.

Das sind zwei zusätzliche Stories:

• 1c: Als Hotelier möchte ich den optimalen Preis für meine Hotelzimmer an die voraussichtliche Belegung anpassen.
• 1d: Als Hotelier kann ich Parameter festlegen, die den optimalen Preis beeinflussen, wie beispielsweise die gewünschte Zimmerauslastung, die Mindestauslastung und die Maximalauslastung (könnte über 100%.

Fazit zum Aufsplitten von Epics

Fast alle Teams haben anfangs Probleme, User Stories richtig aufzusplitten. Erfahrungsgemäß macht es aber irgendwann innerhalb des ersten Jahres “Klick” und dann wissen die Teammitglieder, wie sie die Stories speziell für ihr Fachgebiet und ihre Projekte splitten müssen. Wenn Sie mit Agile oder User Stories also noch nicht so vertraut sind, bleiben Sie dran – mit der Zeit wird es einfacher!