Wat is een user story?

Een user story is een korte, in gewone taal opgestelde beschrijving van een wijziging, verteld vanuit het perspectief van degene die er baat bij heeft: „Als terugkerende klant wil ik inloggen met mijn e-mailadres, zodat ik mijn bestelgeschiedenis kan bekijken.” Het is bewust geen specificatie. De kaart belooft een gesprek op gang te brengen, en de details worden duidelijk wanneer het team het verhaal verder uitwerkt, de acceptatiecriteria opstelt en de omvang ervan vaststelt.

Al het overige in deze handleiding is gebaseerd op stories. Het zijn de stories die bij planning poker worden ingeschat, waaraan story points worden toegekend en die worden opgesplitst wanneer de schatting niet tot overeenstemming leidt. Een team dat slechte stories schrijft, zal slecht inschatten, hoe goed de sessie ook wordt geleid, omdat de problemen al bij de input beginnen.

Het format: rol, doel, voordeel

De klassieke vorm stamt uit de tijd van Connextra, een XP-team uit Londen, rond 2001:

Als [rol] wil ik [doel], zodat [voordeel].

Drie sleuven, en elk daarvan vervult een bepaalde functie.

• De rol geeft aan wie de waarde ontvangt. „Als gebruiker” is de meest voorkomende fout in dit format: een verhaal dat over iedereen zou kunnen gaan, is een verhaal waarmee niemand daadwerkelijk heeft overlegd. Noem de specifieke persoon: de terugkerende klant, de integratieontwikkelaar.
• Het doel is de functionaliteit vanuit het perspectief van de gebruiker, waarbij wordt beschreven wat de persoon doet in plaats van hoe het systeem is opgebouwd. „Ik wil mijn wachtwoord opnieuw instellen” is een doel. „Ik wil een microservice voor het opnieuw instellen van wachtwoorden” is een ontwerpbeslissing die deze vorm heeft aangenomen.
• Het voordeel is de clausule die teams als eerste schrappen, en het is deze clausule die ervoor zorgt dat de kaart een plaats in de backlog krijgt. Het „zodat” is het argument waarom dit onderdeel op de planning moet worden geplaatst. Als niemand het kan voltooien, heeft het werk geen bestaansrecht, en door de clausule op te schrijven komt u daarachter voordat de sprint begint, in plaats van erna.

Kaart, gesprek, bevestiging

Ron Jeffries heeft de werking van verhalen samengevat in drie C’s, waarbij de volgorde van belang is.

De kaart is een symbool: een of twee zinnen, bewust kort gehouden. De omvang ervan is een kenmerk: er kan fysiek geen volledige vereiste op worden vermeld, waardoor de volgende C onvermijdelijk volgt.

Het gesprek is de plek waar de vereiste daadwerkelijk tot uiting komt. Het team en de producteigenaar bespreken het verhaal tijdens de backlogverfijning: de randgevallen en wat expliciet buiten de scope valt. Teams die dit overslaan en de kaart als de vereiste beschouwen, krijgen het slechtste van twee werelden: een document dat te summier is om op voort te bouwen, en geen gesprek omdat „het al opgeschreven staat“.

De bevestiging vormt de acceptatiecriteria: de voorwaarden voor ‘geslaagd’ of ‘niet geslaagd’ die aangeven of het voltooide werk voldoet aan wat er tijdens het overleg is overeengekomen. In het hoofdstuk over het sjabloon voor user stories worden de twee geschikte formats getoond, en in het hoofdstuk over acceptatiecriteria wordt uitgebreid ingegaan op het opstellen ervan.

De INVEST-checklist

De checklist van Bill Wake uit 2003 is nog steeds de snelste manier om te toetsen of een verhaal klaar is om aan te werken. Een goed verhaal is:

• Onafhankelijk: kan op zichzelf worden ingepland, zonder dat er drie andere stories bij de sprint worden betrokken.
• Onderhandelbaar: de kaart nodigt uit tot een gesprek; de reikwijdte kan nog veranderen. Een verhaal waarin elk detail vastligt, is een vereiste die zich voordoet als een verhaal.
• Waardevol: de „zodat“-zin houdt stand bij één oprechte „waarom?“.
• Inschatbaar: het team kan er een getal aan toekennen. Een story waarvan niemand de omvang kan inschatten, houdt een onbekende factor in; voer een spike uit om deze te bepalen.
• Klein: past ruimschoots in een sprint. Als dat niet het geval is, splits het dan.
• Testbaar: u kunt acceptatiecriteria opstellen die slagen of mislukken. „De pagina voelt sneller aan” voldoet niet aan dit criterium; „de resultaten worden binnen een seconde geladen” voldoet wel aan dit criterium.

Bij ‘Estimable’ en ‘small’ komen de verhalen samen met de rest van deze handleiding. Een grote spreiding in de stemmen bij planning poker duidt meestal op een INVEST-fout die pas laat aan het licht komt: het verhaal was op manieren onderhandelbaar die niemand in overweging had genomen, of te omvangrijk om in zijn geheel te kunnen overzien.

Wat een user story niet is

Geen taak. Een verhaal levert iets op wat een gebruiker kan zien; een taak is een stap die het team zet om dat te bereiken. „Inloggen met e-mail” is een verhaal. “De sessieopslag instellen” is een van de taken daarvan. In het hoofdstuk over epics, stories en taken wordt de hiërarchie besproken en wordt uitgelegd waarom punten uitsluitend op het story-niveau thuishoren.

Geen document met specificaties. Een specificatie moet volledig zijn voordat met het werk wordt begonnen. Een user story moet voldoende zijn om het gesprek op gang te brengen en niet meer dan dat. Het beoordelen van user stories aan de hand van specificatienormen („het is te vaag!”) gaat voorbij aan de opzet: de vaagheid is bewust ruimte gelaten voor het oordeel van het team.

Dit is geen toezegging dat de oplossing ook daadwerkelijk zal worden geïmplementeerd. Het verhaal bepaalt het eindresultaat; het team bepaalt zelf hoe dit wordt bereikt. Wanneer een verhaal wordt aangedragen waarbij de oplossing al vooraf vastligt, is het onderhandelbare deel van INVEST al verdwenen.

Wanneer user stories niet het juiste hulpmiddel zijn

Het formaat kent zijn beperkingen, en doen alsof dat niet zo is, kost u uw geloofwaardigheid bij degenen die de lastige zinnen moeten schrijven. In sommige zinnen komt het woord ‘gebruiker’ niet voor:

• Grondig platformwerk. „Als ontwikkelaar wil ik het framework upgraden, zodat het framework wordt geüpgraded” zegt niets meer dan wat de titel van het ticket al aangeeft. Formuleer het als puur technisch werk met een concreet resultaat: wat gaat er mis of wordt trager als dit niet gebeurt, en wat wordt er gemakkelijker als het wel gebeurt.
• Fouten waarvan de oorzaak bekend is. Een foutrapport (verwacht gedrag, werkelijk gedrag, stappen om de fout te reproduceren) is een geschiktere vorm dan een achteraf aangepast verhaal. In het hoofdstuk over verhaalpunten wordt beschreven wanneer fouten worden toegewezen.
• Onderzoekspieken. Een piek bestaat uit een vraag en een tijdsbestek, en levert kennis op. Door dit te dwingen in het kader van rol-doel-voordeel, wordt juist datgene verdoezeld wat er echt toe doet: wat het team moet leren.
• Nalevingswerkzaamheden. U kunt met een toezichthouder niet onderhandelen over de reikwijdte. De eis is de eis; leg deze als zodanig vast.

Wat al deze voorbeelden gemeen hebben, is de discipline, niet de vorm van de zin: een duidelijk omschreven reden waarom het werk van belang is, en een toetsbare definitie van wat ‘voltooid’ inhoudt. Als u zich daaraan houdt, heeft het format zijn doel bereikt, zelfs wanneer het niet van toepassing is.

Waar verhalen en schattingen samenkomen

Een story vormt de eenheid voor het inschatten. Zodra deze is opgesteld, doorloopt het traject de volgende stappen: het team bespreekt de story, schat de omvang ervan in story points met behulp van planning poker, toetst deze aan de definitie van ‘klaar’ en splitst de story op indien de stemming geen overeenstemming oplevert. Een goed opgestelde story versnelt al deze stappen, wat de praktische reden is om überhaupt aandacht te besteden aan de opmaak.

Om te zien hoe het formaat in de praktijk wordt toegepast, worden in het hoofdstuk met voorbeelden van user stories zestien verhalen met toelichting besproken, zowel goede als slechte. Om uw eigen verhaal te schrijven, kunt u beginnen met het sjabloon.

Veelgestelde vragen

Wat is een user story?

Een user story is een korte, in gewone taal opgestelde beschrijving van een wijziging, verteld vanuit het perspectief van degene die er baat bij heeft: „Als terugkerende klant wil ik inloggen met mijn e-mailadres, zodat ik mijn bestelgeschiedenis kan bekijken.” Het is bewust geen specificatie. De kaart dient als uitgangspunt voor een gesprek, en de details worden pas vastgesteld wanneer het team het werk verder uitwerkt en de omvang ervan bepaalt.

Wat houdt het user story-formaat in?

De klassieke opbouw is rol-doel-voordeel: „Als [rol] wil ik [doel], zodat [voordeel].“ De rol geeft aan wie de waarde ontvangt, het doel benoemt de functionaliteit in de termen van de gebruiker, en het voordeel vormt de reden waarom het werk überhaupt moet worden ingepland. Als niemand de „zodat“-clausule kan invullen, is er geen reden om het verhaal in de backlog op te nemen.

Wat zijn de drie C’s van user stories?

Kaart, gesprek, bevestiging. De kaart dient als herinnering en is bewust te klein om de volledige vereiste te bevatten. Het gesprek is de plek waar de vereiste daadwerkelijk tot leven komt, tijdens de verdere uitwerking samen met het team. De bevestiging bestaat uit de acceptatiecriteria die aangeven of het voltooide werk al dan niet voldoet aan wat is besproken.

Waar staat INVEST voor?

Onafhankelijk, onderhandelbaar, waardevol, inschakelbaar, klein, testbaar. Dit is de checklist van Bill Wake om te bepalen of een story klaar is om aan te werken. De laatste drie punten wegen in de praktijk het zwaarst: een story die het team niet kan inschatten, die niet in een sprint past of waarvan geen enkele test de juistheid kan bevestigen, is een story die nog niet klaar is.

Wanneer dient u geen gebruik te maken van user stories?

Wanneer de opzet meer formaliteit toevoegt in plaats van duidelijkheid. Grondig platformwerk, bugfixes met een bekende oorzaak, nalevingsvereisten en onderzoekspieken hebben allemaal een betere, eigen vorm. Behoud de voordelenclausule en de acceptatiecriteria; laat de „als ontwikkelaar wil ik”-formule achterwege wanneer er geen gebruiker in de zin voorkomt.

Aanbevolen lectuur

• Agile-inschatting: de complete gids. Hier vindt u alle informatie op één plek.
• Voorbeelden van user stories: zestien verhalen met toelichting, waaronder ook voorbeelden die mislukken en de redenen daarvoor.
• Sjabloon voor gebruikersverhalen en acceptatiecriteria: het sjabloon, de varianten daarvan en een uitgewerkt voorbeeld tot en met de schatting.
• Epic vs verhaal vs taak: waar het verhaal zich in de hiërarchie bevindt, en naar welk niveau wordt verwezen.
• Het opsplitsen van user stories: wat te doen wanneer een story niet voldoet aan de ‘small test’.