Zo maak je een user story

29 May 2026

User stories zijn belangrijk voor al onze agile projecten. Regelmatig schuiven we bij klanten aan om ze te ontwikkelen en minstens even vaak krijgen we de vraag om user stories uit te leggen. Tijd om er eens vol in te duiken, dus!

Wat is een user story?

Laten we bij het begin beginnen: een user story is een kort verhaaltje dat beknopt vertelt wat een gebruiker (de user) wil en zou moeten kunnen op of met het te ontwikkelen project. Alle user stories samen vormen een pakket aan wensen en behoeftes waar wij als ontwikkelaars mee aan de slag kunnen. Op basis van de user stories bouwen we uiteindelijk de losse functionaliteiten.

User stories zijn kort. Heel kort. Aan de hand van een wie-wat-waarom format wordt in één zin de user story beschreven.

Waarom gebruik je user stories?

Met user stories willen we natuurlijk een optimale klantbeleving creëren, dat is het uiteindelijke en belangrijkste doel. Maar met user stories bereik je nog veel meer! Zo zorgen we ervoor dat de user stories continue als basis kunnen dienen voor reviews tijdens het proces. Daarnaast merken we dat, wanneer we met onze klanten user stories ontwikkelen, hun bewustwording en betrokkenheid bij het project groeit. Hierdoor kunnen we een betere inhoudelijke bijdrage leveren aan de ontwikkeling van het project.

Persona ontwikkelen

Voor we ook maar iets kunnen zeggen over user stories hebben we een (fictieve) gebruiker nodig. Een persona. Vanuit het perspectief van deze persoon schrijven we de uiteindelijke user stories. Door persona's te ontwikkelen kun je de gebruikers leren kennen en kom je tot belangrijke inzichten die je kunnen helpen om user stories te maken. De gebruiker staat straks dus letterlijk centraal.

Een persona ontwikkel je door iemand uit je belangrijkste doelgroep in gedachten te nemen, vervolgens geef je hem of haar een naam en eventueel een foto. Daarna bedenk je relevante kenmerken en gedragingen van deze persoon, zoals leeftijd, leefstijl, gebruikspatronen en merkloyaliteit.

Epics ontwikkelen

Om goede user stories te ontwikkelen werken we eerst met grote(re), grove(re) verhalen. Dit zijn nog wat vage beschrijvingen van een wat een gebruiker wil. Epics noemen we dat. Hiermee voorkomen we dat we direct op de details inzoomen, met het risico dat we belangrijke punten over het hoofd zien.

Om een epic te maken, schetsen we het perspectief van de persona. Waar krijgt de gebruiker mee te maken bij het bereiken van zijn of haar belangrijkste doel? Het antwoord op deze vraag leidt vaak tot de belangrijkste epics en dat is perfect materiaal om user stories van te maken.

Voor een goede epic moeten we antwoord hebben op 6 vragen:

Wat is het doel van de gebruiker?
Waarom heeft de gebruiker dit doel?
Welke kanalen gebruikt de gebruiker om zijn/haar doel te bereiken?
Welke vragen heeft de gebruiker bij het bereiken van zijn/haar doel?
Welke beslissingen of keuzes moet de gebruiker maken?
Welke ervaring heeft de gebruiker?

Met de antwoorden op deze vragen kunnen we de epic uitschrijven in een globale zin of korte alinea van ongeveer 4 à 5 regels.

Refinement: van epic naar user-story

Epics geven ons een goed beeld van de grote lijnen, maar om ze bruikbaar te maken splitten we de epics op in kleinere, gedetailleerde user stories totdat ze klaar zijn: duidelijk, uitvoerbaar en testbaar. Aan de aan hand van het INVEST principe bepalen we vervolgens of de user stories van voldoende kwaliteit zijn.

Waar een user story aan moet voldoen: het INVEST principe

Het acroniem INVEST staat voor een reeks criteria die we gebruiken om user stories te beoordelen. Voldoet een user story niet aan alle criteria? Dan verwoorden we de user story anders of herschrijven we het volledig. Goede user stories zijn:

Independent (Moet op zichzelf staan en niet afhankelĳk zijn van andere stories)
Negotiable (Legt de essentie van de behoefte van de gebruiker vast, houdt ruimte voor veranderingen)
Valuable (Heeft waarde voor de eindgebruiker)
Estimable (De grootte kan goed worden ingeschat zodat het geprioriteerd kan worden en in sprintplanningen past)
Small (Klein genoeg om binnen een week te ontwikkelen en te testen)
Testable (Kan worden getest aan de hand van ‘definition of done’ en ‘acceptance criteria’)

Hoe ziet een user story eruit?

Ja tof, persona's maken, epics maken, user stories maken... maar hoe ziet dat er in de praktijk uit? Hoe zien user stories eruit? Laten we een voorbeeld maken, eentje die dicht bij het onderwerp van dit blog ligt: user stories ordenen in het backlog.

De behoefte van de gebruiker zou dan kunnen zijn:

Ik wil mijn user-stories in het backlog opnieuw ordenen, dat is momenteel niet mogelijk. Het is goed als ik mijn user stories kan markeren met een prioriteit zodat ik ze in het backlog kan prioriteren. Het zou ook goed zijn als ik in een sprint de voortgang kan zien in hoeverre verschillende user-stories zijn afgerond.

Om te voorkomen dat we direct op de details ingaan beschrijven we de grote lijnen van deze behoefte. De epic ziet er dan als volgt uit:

Bied de gebruiker opties om de volgorde en prioriteit van de user-stories in het backlog eenvoudig te beheren.

Om deze epic duidelijk, uitvoerbaar en testbaar te maken, splitsen we het in meerdere user stories aan de hand van een een wie-wat-waarom format:

User-story 01: Als releasemanager wil ik dat mijn user-stories in verschillende sprints gegroepeerd kunnen worden, zodat ik per sprint alleen de belangrijkste user stories zie.

User-story 02: Als systeembeheerder wil ik kunnen bepalen wie de prioriteit van user-stories kan veranderen, zodat alleen bekwame mensen deze actie kunnen uitvoeren.

User-story 03: Als developer zou ik eenvoudig een nieuwe prioriteit willen aangeven door middel van drag-and-drop, zodat ik makkelijk de prioriteit kan aangeven en veranderen.

Voordat we de user stories gebruiken testen we ze aan de INVEST criteria. Voldoet een user story aan elke criteria? Dan gaan we ermee aan de slag en maken we toffe, badass, maar vooral gebruiksvriendelijke functionaliteiten voor jouw webshop!