Lukt het je om user stories te splitsen totdat ze klein genoeg zijn? Zo klein dat het agile team ze in minder dan een halve sprint of liever nog in 1 of 2 dagen kan realiseren?
Bij het splitsen van user stories is de uitdaging om de kleine stories aan het businesswaarde-criterium te laten voldoen. Ook de gesplitste user stories moeten op zichzelf van toegevoegde waarde zijn voor de business. Zeker beginnende teams hebben daar nogal eens moeite mee.
User stories splitsen met behoud van businesswaarde
Ik heb epics en user stories op allerlei creatieve manieren gesplitst zien worden. Om je op het rechte pad te houden heeft user story guru Mike Cohn in 2017 de SPIDR-techniek geïntroduceerd (zijn boek User Stories Applied is absoluut een must read).
Ken je die techniek al?
Het is een eenvoudig te leren techniek. En als je doorhebt hoe het werkt, is het niet moeilijk meer om ook hele kleine user stories met businesswaarde te definiëren.
Je hoeft slechts 5 eenvoudige tactieken om user stories te splitsen te kennen. Vrijwel elke user story is met behulp van deze 5 tactieken te splitsen. Om de tactieken gemakkelijk te onthouden zijn ze samengebracht in het acroniem SPIDR.
De SPIDR-techniek
De letters in SPIDR staan voor de volgende 5 tactieken om user stories te splitsen met behoud van businesswaarde:
S – Spike
SPIDR staat voor: Spike, Path, Interface, Data, Rules. Soms is een user story niet duidelijk of te complex en is er meer informatie nodig om hem zinvol 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.
P – 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.
I – Interfaces
Dit is een goede optie als de functionaliteit via verschillende interfaces aangeboden moet worden, en daardoor de ontwikkeltijd substantieel groter is. Je kunt dan bijvoorbeeld voor de interface van de website en die voor 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.
D – 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.
R – 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 SPIDR
“Het grote voordeel van deze techniek vind ik de toegankelijkheid. SPIDR is concreet genoeg om snel ter zake te komen. 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.
Mijn ervaring is dat ontwikkelaars 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. Probeer het zeker uit.”
Mocht je meer hulp kunnen gebruiken, kijk dan eens bij onze online training Juwelen van user stories voor het splitsen van user stories mét behoud van businesswaarde. Dan ontdek je hoe je met een simpele techniek een overzichtelijk backlog met waardevolle user stories creëert.
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.
Nicole de Swart & Priya Soekhai
Het opsplitsen van werk in kleinere, beter behapbare delen is natuurlijk een goed idee en bovenstaande kan daar mooi gestructureerd weer bij helpen. Toch blijft het altijd erg oppassen; levert elk onderdeel nog wel een op zichzelf staand resultaat op? Bijvoorbeeld het splitsen van betaalmogelijkheden over de verschillende payment providers (pin, Visa, Mastercard, PayPal) is een mooi voorbeeld waar dat kan. Maar bijvoorbeeld factuurberekeningen en BTW splitsen is dat niet; het een kan niet zonder het ander. En dus moet je dan toch weer alles bij elkaar houden, anders heb je geen business value aan het eind van de sprint. Dat geldt vaak ook voor Rules; als er een Rule ontbreekt, is het niet af. Of wat ik deze week nog meemaakte; een nieuwe app die maar half af was. Helaas, het was dus meteen “delete” want niet bruikbaar en de kans dat ik nog eens terugkom is niet groot.
Het is het algemene probleem waar je tegenaan kunt lopen; sommige dingen zijn nu eenmaal niet verder te splitsen dan helaas toch grote brokken werk. Of gaan we in de toekomst een zwangerschap ook in 18 sprints van twee weken doen? 🙂
Ik ben het eens met Ton, opsplitsen is mooi maar hou je hoofd erbij. Anders wordt het splitsen om op te splitsen en gaat de value integraal verloren (dit is volgens mij een van de grootste risico’s van agile).
Opsplitsen zonder de business (waardebewaker) erbij leidt gemakkelijk tot waardeloze ontwikkelingen.
Ik zie trouwens ook veel verwarring tussen waarde en kost. Waarde is wat je krijgt, kost is wat je ervoor betaalt (de ‘je’ is hier altijd de business). Strikt vasthouden aan de duurtijd, zet de poort open naar onoordeelkundige splitsingen die de potentiële waarde vernietigen.
Dank voor het delen van je ervaringen en de voorbeelden. Ik zou er voor kiezen om te grote stories toch te splitsen en ze in opeenvolgende sprints te implementeren. In je voorbeeld zou ik toch het berekenen en toevoegen van de btw in een afgesplitste user story opnemen (en een sprint later implementeren). Nadeel is inderdaad dat je een sprint langer moet wachten met het releasen van de software (als je dat al elke sprint zou doen). Dat is beter dan de user story te groot laten of op een andere, minder wenselijke manier opsplitsen.
Mike Cohn noemt overigens ‘Denken dat alle business rules meteen geïmplemeterd moeten worden’ een misverstand :-).
Ik heb goede ervaringen met het SPIDR acroniem en gebruik het al langere tijd. Het ‘slicen’ van user stories gaat ons team inmiddels goed af, maar soms loop je vast en dan is het handig om het SPIDR plaatje er even bij te pakken. De poster ervan hangt dan ook bij ons aan de muur. Een veel voorkomend probleem is echter een gebrek aan verdieping in de stakeholder (en wat die wil) dan het splitsen van user stories. Het is namelijk prima mogelijk om met kleine stappen waarde toe te voegen. Een mooi voorbeeld daarvan vind ik de recent gelanceerde berichten app van Mijn Overheid. Daar zat in het begin bijna geen functionaliteit in. Je kon alleen je berichten lezen. En meteen een storm van kritiek dat er zo weinig mee kon. Gebruikers verwachten iets dat compleet af is, maar dat is vaak niet reëel. Het gaat dus om verwachtingsmanagement. Maar toch is er toegevoegde waarde: namelijk het niet meer moeten inloggen met DigiD op MijnOverheid en het snel kunnen lezen van je berichten. Slechts enkele weken later kwam er functionaliteit bij (verwijderen van berichten, verplaatsen van berichten). Ik vind dat een mooi voorbeeld van in kleine stappen iets bruikbaars neerzetten (Minimum Viable Product).
Mooi voorbeeld, dankjewel Leander.
Het probleem dat Nicole terecht aankaart is dat we vaak met te grote userstories te maken hebben. Past soms niet in een sprint, wordt niet gehaald kortom lastig. Het splitsen van userstories wil niet zeggen dat de gesplitste userstories ook altijd apart live gaan. Gesplitste userstories opleveren aan gebruikers om te testen, daarna integreren weer gebruikers testen en dan pas live gaan is wel degelijk een mooie optie om het probleem behapbaar en haalbaar te maken en progressie te kunnen laten zien aan de business. Dus ja, ook als het functioneel niet live kan gaan heeft het opsplitsten userstories nut.
Heel mooi om klein te beginnen. Goede techniek. Zelf gebruik ik vaak een uitgebreide versie als de teams wat verder zijn: https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/#flowchart
Wat goed om te lezen dat de SPIDR-techniek reeds bekend is en ook al is toegepast! Ik begrijp de kritische kanttekeningen. Uiteraard moet je altijd goed afwegen wanneer en hoe je een techniek inzet. Ik ben het wel eens met Nicole. Ik heb te vaak meegemaakt dat te grote user stories sprint na sprint niet werden opgeleverd omdat het zo groot was en moest blijven uit angst dat we anders niet alles zouden realiseren. Met als gevolg dat het dat het werk nooit af komt omdat het niet te overzien is. Ik leg het niemand op hoor, maar de ervaring leert wel dat user stories die klein genoeg zijn veel beter in te schatten zijn waardoor ook beter behapbaar qua realisatie. Mijn ervaring is dat het toepassen van SPIDR ook een positief effect heeft op de samenwerking met de business. De opsplitsing zorgt ervoor dat je met focus kunt samenwerken zonder te verdwalen in allerlei scenario’s/details. Zo krijg je al doende een product/dienst die echt businesswaarde oplevert omdat de business gaandeweg veel beter gaat inzien wat wel en wat geen toegevoegde waarde oplevert.
“Ik heb te vaak meegemaakt dat te grote user stories sprint na sprint niet werden opgeleverd omdat het zo groot was en moest blijven uit angst dat we anders niet alles zouden realiseren.” Dit heeft meer te maken met de inschatting van de story en daar heb je goede professionals voor nodig. Het opknippen in kleinere stories maakt het beter te overzien, maar zorgt er netto niet voor dat een team de juiste inschatting maakt van wat ze binnen een sprint kunnen realiseren. Of het team nou een grote story oppakt, of drie kleine stories, in beide gevallen krijgen ze het niet af als het teveel is. Waar teams veel meer behoefte aan hebben is volledig begrijpen wat de story inhoudt, groot of klein. En dat bereik je met goede professionals, daar ontbreekt het nog vaak aan..
Dag Jan Jaap, bedankt voor je kritische kanttekening. Je hebt gelijk. Een leidraad alleen is niet voldoende. Inschatten is sowieso een onderwerp op zich. Daar heb je inderdaad professionals voor nodig en ervaren collega’s, maar ook stakeholders die willen samenwerken. Dus mensen die inzicht willen/durven te geven in de materie. Mijn ervaring is dat deze personen vaak schaars zijn in organisaties en ondanks hun professionaliteit & ervaring ook niet onfeilbaar zijn. Teams mogen wat mij betreft al doende leren, ook van hun fouten. Een goede, toegankelijke leidraad helpt teams vaak in ieder geval op weg. Het maakt een eind aan oeverloze discussies en aan de afhankelijkheid van anderen. En mocht bij een sprintreview blijken dat het toch anders moet, dan wordt de noodzaak voor de betrokkenheid van stakeholders, ervaren collega’s/ professionals nogmaals geaccentueerd. Iedere zichzelf respecterende organisatie die beweert agile te (willen) werken hoort hier bewust van te zijn.
Ik kan het niet laten nog even te reageren.
Zelf zie ik, moet ik zeggen, absoluut voordelen in de hele Agile mindset. Een van de allergrootste voordelen is dat er op korte termijn “iets” wat opgeleverd, wat echte business value heeft en aan de hand waarvan dan echte feedback kan worden verzameld om verdere verbeteringen aan te brengen.
Maar wat zie je heel vaak gebeuren; dat juist dit basisprincipe niet wordt gehandhaafd. Een factuur zonder BTW is gewoon niet af, het heeft geen enkele business value, je kunt het niet gebruiken, het is zelfs strafbaar, kortom, het is gewoon net als vroeger: een stukje van een langer project. En een systeem waar een Rule niet in zit waardoor je niet voldoet aan wet- en regelgeving: idem dito (en zeker heeft Nicole een punt: niet alle Rules zijn in één keer nodig).
Een tijd geleden was ik bij een bijeenkomst waarin de spreker met droge ogen een prachtig traject stond te vertellen waarin in 26 sprints in een jaar tijd keurig op tijd op 31 december een nieuw financieel product aan de klant was opgeleverd. Iedereen slikte het als zoete koek. Pas in de pauze bedacht ik me dat hij gewoon een klassieke projectaanpak had geschetst. Het resultaat was prima verder, maar als je geen Agile wilt of gewoon niet nodig hebt, doe dan ook niet alsof.
Dus wat spreken we af? We gaan geen pijpen kopen, pijpen lijmen, pijpen monteren etc. etc.. Nee, we gaan eerst een regenpijp aan de achterkant van het huis maken. En vervolgens een aan de voorkant. Als je het zo functioneel opsplitst, dan hou je het hanteerbaar en voldoe je tenminste aan een van de sterkste pluspunten die Agile te bieden heeft.
Hallo Ton, ik denk dat we het grotendeels eens zijn. Het voordeel waarmee je begint onderschrijf ik volledig. Als het opsplitsen van een user story ertoe leidt dat er op korte termijn geen businesswaarde wordt opgeleverd, kun je beter niet opsplitsen.
In te grote user stories schuilt echter het gevaar dat er te lang geen software opgeleverd en/of niet noodzakelijke functionaliteit alvast meegenomen wordt. Als je dan toch bijvoorbeeld de btw afsplitst (om bij het eerdere voorbeeld te blijven), onder de voorwaarde dat ze in OPEENVOLGENDE sprints geïmplementeerd worden, kun je al meteen echte feedback terugkrijgen.
Ik denk dat hierbij vooral het onderscheid tussen acceptatie- en productieomgeving gemaakt moet worden. Je kunt prima wetgeving onvolledig aanbieden, zolang dit nog niet ‘live’ gaat, maar wel door de (interne) klant wordt geevalueerd. Wij werken zelf aan een intern product met veel kleine modules. Meerder modules hebben maandenlang de status “Experimenteel”. Dit houdt in dat resultaten van deze modules niet naar klanten mogen omdat er onvoldoende zekerheid is over de juistheid van de uitkomsten.
Het acroniem kende ik nog niet, maar deze verschillende tactieken passen we al toe 🙂 (hoe kan het ook anders)
De uitdaging bij ons is niet zo zeer dat de user stories te groot zijn, maar dat de user stories user stories zijn. Vaak wordt een wens voorgesteld als een fout of een probleem met de software en moet eerst het onderliggende probleem en de bedrijfs-/klantwaarde worden opgespoord.
Daarbij hebben we als extra uitdaging dat degenen die ons werk evalueren verspreid zitten over verschillende afdelingen en dat binnen elke afdeling een eigen werkwijze is en visie op de ontwikkeling en ook dat deze mensen zichzelf hiervoor vrij moeten maken uit de dagelijkse productie. Van dat laatste punt heb ik het idee dat voor stress zorgt en stress vermindert creativiteit en op zijn beurt verkleint dat weer de kans op het vinden van goede oplossingen.