Het opsplitsen van Epics

Een Scrum Trainer vroeg me onlangs naar een paar goede voorbeelden waarbij grote User Stories (Epics) werden opgesplitst in kleinere Stories. Deze voorbeelden wil ik graag met je delen.

Epic 1: De juiste marketingcampagne vinden

Het eerste voorbeeld gaat over een bedrijf dat software verkoopt aan grote retailondernemingen (WalMart etc.). Het hoofd van de marketingafdeling moest beslissen hoe het reclamebudget besteed zou worden. Daarom werd de User Story (Epic) vanuit zijn perspectief geschreven. Zijn eerste grote doel was:

Als hoofd van de marketingafdeling wil ik de eerdere reclamecampagnes kunnen bekijken, zodat ik lucratieve campagnes kan identificeren en herhalen.

De teamleden zeiden dat dit duidelijk een Epic was. Dus vroeg ik hen om er meerdere kleinere Stories van te maken:
1a: Als hoofd van de marketingafdeling wil ik een tijdsperiode kunnen selecteren waaruit de te beoordelen reclamecampagnes afkomstig zijn, zodat…
2a: Als hoofd van de marketingafdeling wil ik kunnen kiezen welke campagnes (huis-aan-huisreclame, tv, e-mail, radio enz.) in de beoordeling worden meegenomen, zodat….

(Let op: ik heb de stories zo genummerd dat je kunt zien van welke oorspronkelijke story ze afstammen. In een echt project zou ik dat niet per se doen – tenzij ik een tool zou hebben waarbij dat automatisch gebeurt.)

Ik wist niet precies hoe groot deze twee stories waren en of ze nog een keer opgesplitst moesten worden. Dus vroeg ik het team: "Als jullie deze stories zouden moeten inschatten, welke eenheid zou je dan als eerste te binnen schieten? Uren, dagen, weken, maanden of jaren?" Bij 1a waren het dagen, dus de story bleef zoals hij was. Bij 1b waren het weken en daarom splitsten we de story nog een keer op:

• 1b1: Als hoofd van de marketingafdeling wil ik informatie over huis-aan-huisreclame van eerdere campagnes kunnen bekijken, zodat…

• 1b2: Als hoofd van de marketingafdeling wil ik informatie over tv-reclame van eerdere campagnes kunnen bekijken, zodat…

• 1b3: Als hoofd van de marketingafdeling wil ik informatie van eerdere campagnes met e-mailreclame kunnen bekijken, zodat…

• enz.

Elk van deze stories had een goede omvang ("we zouden deze story in dagen inschatten"). Ze hadden echter nog bepaalde informatie nodig – de zogenaamde "Conditions of Satisfaction", wat in feite high-level acceptatietests zijn. Voor 1b2 schreven de teamleden het volgende op de achterkant van de indexkaart:

• Hoeveel toeschouwers uit welke leeftijdsgroep waren er?

• Hoeveel toeschouwers uit welke inkomensgroep waren er?

Voorbeeld 2: Omzetmaximalisatie van een hotel

In dit voorbeeld gaat het om een hotel waarbij de omzet gemaximaliseerd moest worden, d.w.z. de exploitant wilde de hoogst mogelijke prijs voor de hotelkamers vinden. De prijzen werden berekend op basis van een aantal factoren. Dat waren bijvoorbeeld kamerprijzen van vergelijkbare hotels, het seizoen, grote evenementen in de directe omgeving (als de Super Bowl of een wereldkampioenschap in een stad wordt gehouden, stijgen daar de prijzen) enzovoort.

Dit was de oorspronkelijke User Story (Epic):

1: Als hotelier wil ik de optimale prijs voor mijn hotelkamers vinden.
Voor de eenvoud gaan we er gewoon van uit dat het hotel slechts over één categorie kamers beschikt. Zoals al genoemd, kunnen veel factoren de prijs van een hotelkamer beïnvloeden. De basisformule voor de berekening van de kamerprijs ziet er dan als volgt uit:

Kamerprijs = f (a,b,c…)

Deze functie is afhankelijk van verschillende factoren. Voor elk daarvan is er een Story:
1a: Als hotelier wil ik de optimale prijs voor mijn hotelkamers vaststellen op basis van de prijzen van vorig jaar.
1b: Als hotelier wil ik de optimale prijs voor mijn hotelkamers vaststellen op basis van de prijzen van vergelijkbare hotels.

Story 1a zegt alleen dat de prijzen van het voorgaande jaar in de functie worden meegenomen. Story 1b zegt dat ook de prijzen die andere hotels vragen, in de berekening worden meegenomen.

Elk van de Stories was relatief groot (een Epic) en uiteraard waren er meer dan de twee hierboven genoemde Stories. Daarom zou het onmogelijk zijn geweest om ze allemaal in één Sprint te stoppen. De Stories werden stap voor stap geïmplementeerd en zo kwam er bij de genoemde formule een onjuiste prijs uit, omdat ze als volgt werd opgebouwd:

Kamerprijs = f (a)

dan

Kamerprijs = f (a,b)

dan

Kamerprijs = f (a,b,c)

enzovoort.

Na de eerste Sprint zou de berekening dus Kamerprijs = f (a) zijn en zou je een onjuiste prijs krijgen (die niet aan de klant doorgegeven kan worden). De berekening op zich is echter in principe correct. Misschien zijn de waarden voor (b) en (c) hard gecodeerd of worden ze simpelweg genegeerd. Maar op deze manier kunnen zulke complexe algoritmen incrementeel worden opgebouwd.

Omdat Story 1b nog steeds te groot was, werd deze opnieuw opgesplitst:

• 1b1: Als hotelier kan ik een bepaald aantal vergelijkbare hotels vastleggen. (Hiervoor werd de term "Comparable Set" in dit bedrijf gebruikt.)
• 1b2: Als hotelier kan ik hotels aan het Comparable Set toevoegen.
• 1b3: Als hotelier kan ik hotels uit het Comparable Set verwijderen.
• 1b4: Als hotelier kan ik een compleet Comparable Set verwijderen dat ik niet meer nodig heb.
• 1b5: Als hotelier oriënteer ik me op de kamerprijzen van de hotels in een bepaald Comparable Set om mijn kamerprijzen te bepalen.

Dat zijn twee aanvullende Stories:

• 1c: Als hotelier wil ik de optimale prijs voor mijn hotelkamers aanpassen aan de verwachte bezetting.
• 1d: Als hotelier kan ik parameters vastleggen die de optimale prijs beïnvloeden, zoals bijvoorbeeld de gewenste kamerbezetting, de minimale bezetting en de maximale bezetting (kan boven de 100% liggen).

Conclusie over het opsplitsen van Epics

Bijna alle teams hebben in het begin moeite om User Stories goed op te splitsen. De ervaring leert dat het op een gegeven moment binnen het eerste jaar "klikt" en dan weten de teamleden hoe ze de Stories specifiek voor hun vakgebied en hun projecten moeten splitsen. Als je met Agile of User Stories dus nog niet zo vertrouwd bent, blijf erbij – met de tijd wordt het makkelijker!