gebruik de SPIDR techniek als de user stories te groot zijn Lukt het je om de user stories klein genoeg te maken? Zijn ze zo klein dat het ontwikkelteam ze in minder dan een halve sprint of liever nog in 1 of 2 dagen kan realiseren?

Ik heb epics en user stories op allerlei creatieve manieren opgesplitst zien worden. Het is de kunst om ervoor te zorgen dat ook de kleine stories aan het businesswaarde-criterium voldoen. Ze moeten immers op zichzelf van toegevoegde waarde zijn voor de business. Zeker beginnende teams hebben daar nogal eens moeite mee.

Als je eenmaal doorhebt hoe het werkt, is het niet moeilijk meer ook hele kleine user stories met businesswaarde te definiëren. Om je daarbij te helpen heeft user story-guru Mike Cohn in 2017 de SPIDR-techniek gelanceerd.

De SPIDR-techniek

Ken je deze techniek al? Vrijwel elke user story is met behulp van 5 eenvoudige tactieken te splitsen. Om ze gemakkelijk te onthouden zijn ze samengebracht in het acroniem SPIDR.

De letters in SPIDR staan voor: SPIDR staat voor: Spike, Path, Interface, Data, Rules

Spike – Soms is een user story niet duidelijk of te complex en is er meer informatie nodig om hem zinvol op te splitsen. Laat het team dan een spike uitvoeren. Dat is een timebox waarin een of meer teamleden onderzoeken hoe ze een probleem kunnen oplossen. Bijvoorbeeld door een prototype te bouwen.
Een spike is eigenlijk de laatste optie om een user story te splitsen, maar het acroniem begint nou eenmaal met de S.

Path – Als een user story uit meerdere paden of scenario’s bestaat, kun je die in een afzonderlijke story opnemen. Je hoeft niet elk scenario af te splitsen, alleen als dat zinvol is. Bijvoorbeeld een user story waarin de klant online kan betalen met iDeal of creditcard. Hier kun je twee afzonderlijke user stories van maken of nog verder splitsen in een user story alleen voor betaling met een VISA creditcard.
Wanneer er ‘en’ of ‘of’ in de user story-zin staat, wijst dat er vaak op dat je meerdere scenario’s kunt afsplitsen.

Interfaces – Dit is een goede optie als de functionaliteit via verschillende interfaces aangeboden moet worden, en dat de ontwikkeltijd substantieel groter maakt. Je kunt dan bijvoorbeeld voor de website-interface en de mobiele app afzonderlijke user stories maken. Of nog verder splitsen in Android en iOS. Een andere mogelijkheid is alleen een minimale user interface bouwen en de styling in een afzonderlijke story opnemen.

Data – Veel user stories kun je op basis van de gewenste of benodigde gegevens splitsen. Het toevoegen van BTW aan verkoopprijzen zou bijvoorbeeld in een afzonderlijke story kunnen. Bij gegevensinvoer kun je correcte en foutieve invoer scheiden. Verder is het vaak handig om een grote user story met gegevens uit verschillende bronnen te splitsen. Bij een routeplanner ligt het bijvoorbeeld voor de hand om verkeersinformatie via een afzonderlijke story toe te voegen.

Rules – Als in een (te) grote user story een bepaalde bedrijfsregel, niet-functionele requirement, standaard of wet nageleefd moet worden, is dat een kandidaat voor een af te splitsen user story. Bijvoorbeeld bij een inkoopproces waarbij voor bestellingen boven een vastgesteld bedrag goedkeuring van een leidinggevende is vereist, kun je het verlenen van goedkeuring eenvoudig afsplitsen.

Priya over de SPIDR-techniek:
“Het grote voordeel vind ik de toegankelijkheid. SPIDR is concreet genoeg om snel ter zake te komen. Mijn ervaring is dat ontwikkelteams er graag mee aan de slag gaan om epics en user stories verder uit te splitsen en in samenwerking met de business vaststellen wat er nodig is. Het is een makkelijk hanteerbare leidraad en geeft op een eenvoudige doch gestructureerde wijze inzicht in alles wat belangrijk is qua requirements en aanvullende informatie van een user story. Probeer hem zeker uit.”

Wat is jouw ervaring met het splitsen van epics en user stories? Denk je dat de SPIDR-techniek je daarbij kan helpen? Laat het ons weten in een reactie hieronder.


 

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Share This