Daar zit je dan met je User Story. Je weet dat je team hier nog niet mee aan de slag kan, en dat is logisch, want deze User Story omvat zo ongeveer het hele project. Veel mensen worstelen met dit probleem. Hoe split je een user story op in kleinere delen op een zinnige manier?

Wat is een User Story

Laten we eerst vaststellen wat een User Story is. Een User Story is een beknopte, informele manier om een stuk functionaliteit te beschrijven vanuit het perspectief van de gebruiker. Hij volgt meestal het formaat: “Als [gebruiker], wil ik [een actie] zodat [voordeel/waarde].” Dat kan van alles zijn: Bijvoorbeeld een lesprogramma, een inschrijfprocedure of een nieuwe applicatie. Wat er belangrijk aan is, is dat het iets beschrijft dat ‘functioneel af’ is. Daarmee wordt bedoeld dat het leidt tot een bruikbaar (deel)product. Dat kan dus dat hele project zijn van hierboven, maar ook een gesplit onderdeel ervan.

Behapbaar en bruikbaar maken van de story door ze te splitten

Waarom zou je een User Story eigenlijk willen splitten? Om het behapbaar te maken. Je kunt niet een heel project of een heel product in één keer maken. Je kunt een olifant immers ook niet in één hap opeten. Dus is het logisch om delen of versies te maken die in één sprint passen.

Waar moet je dan rekening mee houden bij het splitten? Het afgesplitte deel(product) moet waarde leveren en moet, net zoals het product waar het van wordt afgesplit, bruikbaar zijn. Je wilt niet een taartbodem of een laagje vulling opleveren, want die kun je niet verkopen in je taartenwinkel. Je wilt een verticale plak met alle laagjes, inclusief de kers. Dit noemen we verticaal slicen.

Richt je op waarde

Om dan vast te kunnen stellen wat ‘waarde’ is, is het belangrijk om continu je productvisie of productdoel voor ogen te houden. Bij het splitten, maar ook bij het uitwerken van de afgesplitste user stories. Anders loop je het risico dat je features of onderdelen gaat ontwikkelen die eigenlijk niet bijdragen aan dat doel en die dus geen waarde leveren aan de klant of de gebruiker.

Bovendien willen we het deel dat de meeste waarde toevoegt als eerste leveren. Hiervoor moeten we de delen die misschien ook waardevol zijn, maar toch net iets minder, afsplitsen. Met andere woorden, wat is nu écht het belangrijkst voor onze klant? Hiervoor is het begrip MVP (Minimal Viable Product). Dit wil je telkens in de gaten te houden. De centrale vraag is: Wat is minimaal nodig om onze klant zoveel mogelijk bruikbare waarde te geven?

Om dit te illustreren geven we hier een voorbeeld. We zijn bezig om een proces in te richten voor een vergunningsaanvraag voor het plaatsen van een marktkraam. Omdat het om een complex proces gaat, splitten we dit op in delen. Een veelgemaakte fout hierbij is het proces in stappen op te knippen en elke stap zijn eigen User Story te geven. Maar losse stappen leveren in het algemeen geen waarde want ze zijn niet bruikbaar. Dit zou bijvoorbeeld zijn: “Vul het formulier B38 in”. Dit komt neer op het horizontaal in plakjes snijden van de taart, wat leidt tot een taartbodem zonder iets erop. Ik weet immers nog niet of ik mijn marktkraam mag plaatsen.

Als je toch tot iets bruikbaars wilt komen, moet je dus een vereenvoudigd proces uitwerken, dat kan dienen als MVP. Dat houdt bijvoorbeeld in dat het proces (nog) geen uitzonderingen aankan en dat er misschien wat stapjes worden overgeslagen die niet persé nodig zijn. Hierbij is het vaak lastig om niet alles te willen doen en de minst waardetoevoegende zaken weg te laten. In ons proces is dan de vraag: Wat is de meestvoorkomende situatie (die we willen kunnen afhandelen) en wat zijn de uitzonderingen (die we nog niet gaan afhandelen)? In het geval van de vergunningsaanvraag blijkt misschien dat het overgrote deel van de marktkramen gewoonweg op een reguliere markt worden geplaatst. We kunnen een MVP maken door te zeggen: “Akkoord. Ga ter plaatse voordat je je kraam neerzet naar de marktmeester voor aanwijzingen”. In alle andere gevallen: “Vooralsnog niet akkoord. Ga naar loket 1 en overleg met een medewerker”.

Verwachtingsmanagement

Als je op deze manier werkt met MVP’s is de communicatie eromheen overigens wel heel belangrijk. Je levert in korte tijd een heel basaal product op, maar je wilt wel de verwachtingen van je klant managen. De boodschap is: “Kijk, een eerste versie. Laat me snel weten wat je ervan vindt, dan bouwen we daarop voort met een tweede versie”. Anders denkt de klant misschien: “Is dit alles?”, en rekent hij er niet op dat er nog meer komt.

Gebruik acceptatiecriteria om een User story in delen te splitten

Er zijn allerlei manieren om het daadwerkelijke splitten te doen. Zo kun je splitten op basis van deelproducten, deelprojecten of beperkte datasets die je verwerkt. Een bruikbare manier is het spliten op basis van acceptatiecriteria. Elke User Story heeft acceptatiecriteria die ertoe dienen om te bepalen wat precies details en eisen zijn die bij de User Story horen. Elk van deze acceptatiecriteria kan een User Story op zich vormen.

Een voorbeeld. Stel je voor dat je de volgende User Story hebt: “Als huisbewoners willen we graag een groene tuin zodat we daarvan kunnen genieten”, met daarbij de volgende acceptatiecriteria:

• Mogelijkheden om te spelen voor de kinderen
• Ruimte om te zitten, zowel in de zon als in de schaduw
• Droog kunnen zitten, ook als het regent
• Er moeten gevarieerde planten zijn

Van elk van deze criteria kun je weer een User Story maken, met zijn eigen acceptatiecriteria: Als ouder wil ik een speelplek voor mijn twee jonge kinderen en hun vriendjes, zodat ze buiten kunnen spelen en ik er een oogje op kan houden.

• De kinderen moeten met een bal kunnen spelen
• Voldoende ruimte om te kunnen rennen en springen
• Verschillende soorten vermaak
• enz.

Op deze manier wordt het vanzelf behapbaar, bruikbaar en waardevol!

Conclusie

We hebben in deze blog gezien hoe je User Stories split, en hoe dat moet zorgen voor behapbare stukken werk. Hierbij is het belangrijk dat ze gericht zijn op waarde en dat ze bruikbaar moeten zijn. Daarnaast hebben we gekeken hoe je een User Story met behulp van zijn acceptatiecriteria kunt splitten in verschillende delen.

Ben jij door het lezen van dit artikel nieuwschierig geworden hoe de Agile Scrum Group jouw organisatie verder kan helpen? Neem contact op via 020 2614 195 of info@agilescrumgroup.nl, en we helpen je graag verder.

Ook interessant:

• Actie in de Taxi! Hoe ga je over tot actie? Met stappenplan
• Release Train Engineer vs Agile Coach: overeenkomsten & verschillen
• Wat zijn de nadelen van Agile werken
• Root cause analyse: uitleg met praktijkcasus