Wat is een user story?

Een user story is een korte, in gewone taal geschreven beschrijving van een wijziging, verteld vanuit het perspectief van de persoon 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 komen naar voren 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. Deze vormen de basis voor de grootte van de Planning Poker-kaarten, de story points die eraan worden toegekend, en de onderdelen 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 waar niemand daadwerkelijk mee is geraadpleegd. 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 laten vallen, en het is deze clausule die ervoor zorgt dat de kaart een plaats in de backlog krijgt. Het „zodat” is het argument waarom het verhaal op de planning moet worden geplaatst. Als niemand het kan afronden, 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 verfijning van de backlog: de randgevallen en wat expliciet buiten het toepassingsgebied 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 is“.

De bevestiging vormt de acceptatiecriteria: de voorwaarden voor slagen of falen die aangeven of het voltooide werk voldoet aan wat tijdens het overleg is overeengekomen. In het hoofdstuk over het sjabloon voor gebruikersverhalen 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 mee in de sprint worden meegenomen.
• Onderhandelbaar: de kaart nodigt uit tot een gesprek; de reikwijdte kan nog worden aangepast. 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?“-vraag.
• 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 achterhalen.
• Klein: past ruimschoots in een sprint. Mocht dat niet het geval zijn, verdeel 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 gids. 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 waarover niemand had onderhandeld, of te omvangrijk om in zijn geheel te kunnen overzien.

Wat een user story niet is

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

Geen document met specificaties. Een specificatie moet, idealiter, volledig zijn voordat de werkzaamheden van start gaan. Een user story moet voldoende zijn om de dialoog 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 het ontwerp: de vaagheid is juist bedoeld om ruimte te laten voor het oordeel van het team.

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

Wanneer user stories niet het juiste hulpmiddel zijn

Het formaat kent zijn beperkingen, en doen alsof dat niet zo is, ondermijnt de geloofwaardigheid bij degenen die de lastige gevallen moeten opstellen. In sommige zinnen komt de 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, daadwerkelijk gedrag, stappen om de fout te reproduceren) is een geschiktere vorm dan een achteraf aangepast verhaal. In het hoofdstuk over verhaalpunten wordt besproken wanneer fouten worden toegewezen.
• Onderzoekspieken. Een piek bestaat uit een vraag en een tijdsbestek, en levert kennis op. Door dit te forceren in een schema 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 aangegeven reden waarom het werk van belang is, en een toetsbare definitie van ‘voltooid’. 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 van de omvang. Zodra deze is opgesteld, doorloopt het traject de volgende stappen: het team bespreekt de story, schat de omvang in story points in met behulp van planning poker, toetst deze aan de ‘ready’-definitie en splitst de story op indien er geen overeenstemming wordt bereikt bij de stemming. Een goed opgestelde story versnelt elk van 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 het sjabloon als uitgangspunt nemen.

Veelgestelde vragen

Wat is een user story?

Een user story is een korte, in gewone taal geschreven beschrijving van een wijziging, verteld vanuit het perspectief van de persoon 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 vastgelegd 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 mogelijkheid in de termen van de gebruiker, en het voordeel vormt de reden om het werk überhaupt in te plannen. 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 voldoet aan wat is besproken: geslaagd of niet geslaagd.

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 opmaak meer formaliteit toevoegt in plaats van duidelijkheid. Grondig platformwerk, bugfixes met een bekende oorzaak, nalevingsvereisten en onderzoeksspikes hebben allemaal een geschiktere 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 hierover.
• 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.
• Epos versus verhaal versus 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 de ‘small test’ niet doorstaat.