Wat is een user story?

Een user story is een korte, in gewone taal geschreven 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 bevat de belofte om een gesprek aan te gaan, en de details komen pas 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. Dit zijn de elementen die bij planning poker worden ingedeeld, waaraan story points worden toegekend en die worden opgesplitst wanneer de schatting niet tot overeenstemming leidt. Een team dat slechte stories opstelt, 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 bij naam — 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 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 backlogverfijning: de randgevallen en wat expliciet buiten de scope valt. Teams die deze stap 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 goedkeuring of afkeuring die aangeven of het voltooide werk voldoet aan wat tijdens het overleg is overeengekomen. In het hoofdstuk over het sjabloon voor user stories worden de twee geschikte formats weergegeven, 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 story klaar is om aan te werken. Een goede story is:

• Onafhankelijk — kan op zichzelf worden ingepland, zonder dat er drie andere verhalen mee in de sprint worden meegenomen.
• Bespreekbaar — 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. 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.

„Estimable“ en „small“ zijn de punten waarop verhalen aansluiten bij 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 heeft onderhandeld, of te omvangrijk om in zijn geheel te kunnen overzien.

Wat een user story niet is

Geen taak. Een verhaal levert iets op dat 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.

Dit is geen document met specificaties. Een specificatie moet, idealiter, volledig zijn voordat met de werkzaamheden wordt begonnen. 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 de opzet: 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 dat wordt bereikt. Wanneer een verhaal wordt aangedragen waarbij de oplossing al vooraf is vastgesteld, 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, 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” voegt niets toe aan 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 story points wordt uitgelegd wanneer fouten in story points worden uitgedrukt.
• Onderzoekspieken. Een piek bestaat uit een vraag en een tijdslimiet, en levert kennis op. Door het 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 dan ook 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 wat ‘af’ betekent. Zolang 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 de inschatting. 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 er geen overeenstemming wordt bereikt bij de stemming. Een goed opgebouwd verhaal versnelt al deze stappen, wat de praktische reden is om überhaupt aandacht te besteden aan de opmaak.

Om te zien hoe het format 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 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 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 functionaliteit 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 specificatie te bevatten. Het gesprek is de plek waar de specificatie 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, inzetbaar, 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 onderzoeksspikes 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 hierover.
• Voorbeelden van gebruikersverhalen — 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 u moet doen wanneer een story de ‘small test’ niet doorstaat.