De definitie van de term User Story geleidelijk is verschoven. Het betekent inmiddels iets anders dan oorspronkelijk bedoeld. Dit geleidelijk verschuiven van definities van termen komt vaak voor in de IT. In dit artikel bespreken we verschillende soorten definities van User Stories door de jaren heen. Tot slot laten we zien hoe je een goede user story kunt schrijven.
Dit artikel is gebaseerd op een Engelstalig artikel van collega William Gadney. Meer artikelen zijn te vinden op zijn website.
Originele definitie van een User Story
In 1997 introduceerde Kent Beck user stories tijdens het Chrysler C3-project in Detroit.
Hieronder staan enkele definities van de term user story die goed aansluiten bij Becks oorspronkelijke bedoeling:
In softwareontwikkeling en productmanagement is een user story een informele beschrijving in natuurlijke taal van functies van een softwaresysteem. Ze worden geschreven vanuit het perspectief van een eindgebruiker of gebruiker van het systeem, en kunnen worden vastgelegd op indexkaarten, Post-it-notities of digitaal in specifieke beheersoftware.
— Wikipedia
Een user story is een informele, algemene uitleg van een softwarefunctionaliteit, geschreven vanuit het perspectief van de eindgebruiker. Het doel is om duidelijk te maken hoe een feature waarde zal bieden aan de klant.
— atlassian.com
Een user story is een korte, eenvoudige beschrijving van een functionaliteit, verteld vanuit het perspectief van de persoon die de nieuwe mogelijkheid wenst — meestal een gebruiker of klant van het systeem.
— Mountain Goat Software
User stories worden vaak geschreven in het volgende format:
Als een <type gebruiker>, wil ik <een doel> zodat <een reden>.
Naar mijn mening bevinden user stories zich duidelijk in de hoek van de requirements binnen softwareontwikkeling. Ze beschrijven wat het systeem moet doen, voor wie, en waarom het nodig is. Dus: het wie, het wat, en het waarom.
User stories zijn dus geen taken die door teamleden uitgevoerd worden.
Er wordt vaak gezegd dat een user story een placeholder is voor een gesprek over een te implementeren feature. Deze gesprekken zijn waar de échte waarde van een user stories ligt.
Het is logisch om user stories op te nemen in je planning, zodat je kunt bepalen wanneer je dit gesprek voert. Wanneer het gesprek plaatsvindt, zal het resultaat waarschijnlijk een set taken zijn die door verschillende teamleden wordt opgepakt. Deze taken kunnen vervolgens deel uitmaken van de gedetailleerde planning van het team.
Het is echter onlogisch om een user story te beschouwen als een werkitem in een planning dat aan één teamlid wordt toegewezen om af te ronden. Dan mis je het belangrijkste punt van een user story: de uitgebreide discussie over hoe een feature geïmplementeerd dient te worden.
Sfeerbeeld: vrouw bij een Scrum-bord
Nieuwe definitie van een User Story
De afgelopen jaren is de definitie van een user story in sommige contexten aanzienlijk veranderd. Hieronder volgt een definitie van een user story uit het Scaled Agile Framework (SAFe):
Een story beschrijft een klein stukje functionaliteit dat een Agile Team in een paar dagen of minder kan afronden. User stories beschrijven de waarde voor de eindgebruiker. Enabler stories beschrijven het noodzakelijke werk rond exploratie, architectuur, infrastructuur en compliance. Elke story richt zich op specifiek gedrag dat stapsgewijs ontwikkeld kan worden om waarde te leveren aan de gebruiker of de oplossing. Door stories klein te houden, kunnen ze binnen één iteratie worden afgerond, waardoor elke iteratie waarde oplevert.
— framework.scaledagile.com
Hoewel bovenstaande definitie bepaalde elementen van de oorspronkelijke bedoeling van user stories behoudt, is duidelijk te zien dat de focus verschuift. De nadruk ligt niet langer op het identificeren van een requirement die onderwerp zal zijn van een toekomstig gesprek, maar veeleer op het beschouwen van de user story als een werkitem dat binnen enkele dagen voltooid moet kunnen worden.
De volgende paragraaf stelt:
SAFe beschrijft vier niveaus van werkitems die het functioneel gedrag van het systeem specificeren: Epic, Capability, Feature en Story.
— framework.scaledagile.com
Hier zien we dat user stories worden gepositioneerd als werkitems binnen een specifieke laag van een hiërarchische werkstructuur van een project.
Volgens de SAFe-theorie worden epics geïdentificeerd op hoog niveau binnen de managementstructuur van een organisatie. Deze epics worden vervolgens opgesplitst in capabilities, die worden toegewezen aan verschillende Agile Release Trains (ART).
Die capabilities worden op hun beurt opgesplitst in features, die worden toegewezen aan verschillende Scrum-teams binnen een ART. Deze features worden vervolgens opgesplitst in user stories, die op de product backlog van een Scrum-team worden geplaatst en verspreid over meerdere sprints worden gerealiseerd.
Het Scrum-team kan intern een user story opsplitsen in meerdere taken om de story te realiseren, maar dit valt buiten het bereik van wat de SAFe-theorie beschrijft.
Persoonlijk vind ik het moeilijk te geloven dat het opdelen van een hoog-niveau epic in capabilities, vervolgens in features en daarna in user stories, daadwerkelijk resulteert in user stories geschreven vanuit het perspectief van de gebruiker.
Het eindresultaat zal waarschijnlijk bestaan uit zeer technische taken die door een individueel teamlid worden uitgevoerd, waarbij weinig behoefte is aan een gesprek met iemand anders dan de technisch georiënteerde teamleden.
Deze blogpost op scrum.org beschrijft deze veelvoorkomende valkuil: user stories die niet leiden tot de waardevolle gesprekken waarvoor ze oorspronkelijk bedoeld waren.
Het is niet mijn bedoeling om kritiek te leveren op SAFe — ik ben zelf een gecertificeerd SAFe-architect — maar SAFe is wél een goed voorbeeld van dit fenomeen.
Ik denk dat deze top-down benadering — van hoog-niveau doelen naar gedetailleerde taken — erg intuïtief is, en dat meerdere mensen onafhankelijk van elkaar tot hetzelfde idee zijn gekomen.
We moeten ons er alleen van bewust zijn dat onze intuïties ons soms op een dwaalspoor kunnen brengen. De beste ideeën zijn namelijk niet altijd intuïtief.
Als we bijvoorbeeld naar de wereld om ons heen kijken, zou onze intuïtie ons kunnen vertellen dat de aarde plat is — maar de wetenschap heeft aangetoond dat dit niet zo is.
Voorbeelden van goede en slechte user stories
Hieronder volgt een voorbeeld van een user story die ik zou beschouwen als een goede user story:
Als een Online Shopper
Wil ik een product in mijn mandje doen
Zodat ik meerdere producten in 1 keer kan afrekenen
Deze user story zal leiden tot een gesprek tussen verschillende betrokkenen, om samen tot de best mogelijke oplossing te komen.
Daarentegen volgt hieronder een voorbeeld van een user story die ik als minder goed beschouw:
Als een ontwikkelaar
Wil ik een mandje item tabel toevoegen aan de database
Zodat we een record hebben van het mandje van de klant in de database
Deze user story zou hoogstwaarschijnlijk géén gesprek vereisen zoals bij het goede voorbeeld. In de praktijk heeft iemand anders dan al de requirements bepaald, een oplossing ontworpen en deze oplossing opgedeeld in werkpakketten die vervolgens over de schutting worden gegooid naar het ontwikkelteam.
De enige gesprekken die hier nog nodig zijn, vinden intern binnen het team plaats — bijvoorbeeld over hoe de tabel moet heten en welke kolommen erin moeten. Dit is een typisch voorbeeld van big upfront design en programming by remote control.
Dit druist in tegen het hart van agile, en degradeert programmeurs tot niets meer dan code monkeys.
Ik geloof dat een collaboratief ontwerp, tot stand gekomen in samenwerking tussen ontwikkelaars en gebruikers als één team, leidt tot betere oplossingen én tot een gelukkiger en gezonder teamklimaat.
Als de user stories die ik hier als “slecht” bestempel voor jouw team wél werken — waarom zou je dan niet volledig jouw manier van werken omarmen?
Waarom ze überhaupt user stories noemen en niet gewoon tasks? Daarmee vermijd je ook meteen de verwarring en het bagage die de term user story met zich meebrengt.
Het bovenstaande voorbeeld kan dan ook veel eenvoudiger geformuleerd worden als:
Voeg het mandje toe aan het database schema
Hoe herken je een goede user story
Als een top-down aanpak — van hoge organisatiedoelen naar gedetailleerde taken — geen goede manier is om user stories te identificeren, hoe kunnen we het dan wél aanpakken?
We kunnen inspiratie halen uit de wereld van object-oriented programming, waar technische details zoals data en implementatie-logica verborgen zitten in een object. Dat object fungeert als een zwarte doos (black box) en stelt alleen een eenvoudige interface beschikbaar, zodat interactie mogelijk is zonder dat je de interne details hoeft te begrijpen.
Voor user stories kunnen we het gehele systeem op eenzelfde manier als een black box beschouwen, en het beschrijven vanuit het perspectief van de gebruiker buiten het systeem. De “user” in user story is hier essentieel.
Daarnaast is het waardevol om te kijken naar Use Cases uit de UML-methodologie, die als voorlopers van user stories beschouwd kunnen worden. Alistair Cockburn schreef hierover het invloedrijke boek Writing Effective Use Cases (Agile Software Development Series).
Daarin introduceert hij het concept van het sea level: gebruikers-doelniveau, en stelt dat alle use cases idealiter op sea level geschreven worden.
Datzelfde concept van sea level is ook goed toepasbaar op user stories: als alle user stories op dit niveau geschreven zijn, zijn ze onderling beter vergelijkbaar wanneer we er relatieve story points aan toekennen.
De aanpak die ik zelf gebruik om user stories te definieren is als volgt:
- Schrijf een korte beschrijving van het systeem
Eén of twee paragrafen volstaan om te beschrijven wat het systeem wel en niet is. Deze beschrijving dient als referentie om te bepalen of een user story binnen scope valt. Hier geldt: less is more — schrijf niet te veel.
- Identificeer de gebruikers van het systeem
Breng in kaart wie er met het systeem zullen interageren. Dit hoeft niet perfect te zijn, het doel is om snel tot een bruikbare lijst van gebruikersrollen of persona’s te komen.
- Bepaal per gebruiker hun user stories
Neem per gebruiker hun doelen onder de loep: wat willen ze bereiken met het systeem? Vergeet niet: user stories zijn de doelen van deze gebruikers.
- Beoordeel de omvang van de user story – is hij op sea-level?
Ervaring is nodig om aan te voelen of een user story te groot is of te technisch. De grote user stories worden epics genoemd en moeten meestal worden opgesplitst in kleinere, meer behapbare stories. Later kunnen gerelateerde user stories worden gegroepeerd in themes, wat helpt bij het stellen van prioriteiten: eerst tussen themes, dan tussen stories binnen een theme.
- Zorg voor alignment met organisatiedoelen
Controleer of de geïdentificeerde user stories, themes en eventuele hogere groeperingen in lijn zijn met de bredere doelen van je organisatie.
Uit deze aanpak blijkt duidelijk dat het een bottom-up proces is, in tegenstelling tot de vaak toegepaste top-down benadering.
Deze werkwijze bevordert samenwerking, klantgericht denken, en een gedeeld begrip in het team — precies waar agile oorspronkelijk voor bedoeld is.
Conclusie
De term user story is in de loop der tijd verschoven van zijn oorspronkelijke betekenis als gespreksstarter over gebruikersbehoeften, naar een taakgerichte invulling binnen hiërarchische planningsstructuren. Hoewel deze verschuiving begrijpelijk is — en vaak voortkomt uit goedbedoelde pogingen tot structurering — dreigt de kern van het concept verloren te gaan: de focus op de gebruiker, het doel, en de gezamenlijke verkenning van mogelijke oplossingen.
Door een bottom-up aanpak te hanteren, waarbij we beginnen bij de gebruikers en hun doelen, behouden we de essentie van wat een user story zou moeten zijn. Deze aanpak bevordert samenwerking, voorkomt big upfront design en draagt bij aan een gezonde teamcultuur waarin developers geen uitvoerders zijn van andermans plannen, maar actieve deelnemers aan het ontwerpen van waardevolle oplossingen.
Als de werkwijze in je team afwijkt van deze benadering en meer taakgericht is — prima. Maar noem het dan ook zo: tasks. Daarmee blijven we eerlijk over wat we doen en voorkomen we verwarring rond een term die ooit bedoeld was als brug tussen gebruiker en team.
