Wat is een user story?

Regelmatig krijgen wij van klanten de vraag wat een user story is en hoe het wordt toegepast bij het ontwikkeltraject van een nieuwe app of applicatie. User stories zijn een van de belangrijkste onderdelen binnen Scrum en helpt de focus te verleggen van het schrijven over vereisten naar erover praten. User stories zijn daarom korte, eenvoudige beschrijvingen van een eigenschap (feature), zodat projectteams na overleg met de klant of eindgebruiker duidelijk voor ogen hebben wat hij of zij wil. Op basis van een user story kunnen de developers en product owner een schatting maken van de benodigde inspanningen om de nieuwe functionaliteit te ontwikkelen.


Een user story heeft een eenvoudige wie-wat-waarom-structuur:

Concreet betekent dit: Als [klant] wil ik [beschrijving van datgene dat ontwikkeld moet worden] zodat ik [beschrijving van de reden waarom het gemaakt moet worden].

Voorbeeld user story

Als [marketing medewerker] wil ik [eenvoudig afbeeldingen in een groot formaat uploaden en deze automatisch laten voorzien van een watermerk zodat ik [deze handeling niet meer 100x per dag handmatig hoef uit te voeren].

Uit het voorbeeld hierboven wordt duidelijk wat een mogelijke user story is, maar je wilt vast ook weten wat eigenschappen van een goede user story zijn. Dit is gemakkelijk samen te vatten met het woord ‘INVEST’.

Een user story is:

  • I – Independent: beschrijft functionaliteiten die onafhankelijk van elkaar geïmplementeerd kunnen worden.
  • N – Negotiable: is onderhandelbaar. De user story is niet zoals bij traditionele projecten volledig voorgedefinieerd. Het ontwikkelteam krijgt namelijk de ruimte om een user story naar eigen inzicht zo optimaal mogelijk te realiseren.
  • V – Valuable: is waardevol voor tenminste één van de stakeholders.
  • E – Estimable: kan ervoor zorgen dat het team de complexiteit en de benodigde capaciteit bepaalt om de user story te realiseren.
  • S – Small: implementatie van de user story dient korter te duren dan een sprint. Bij user stories die later gerealiseerd worden kan een user story langer duren. Een user story die te groot is om in één sprint te realiseren wordt ook wel een epic genoemd.
  • T – Testable: stakeholders en de product owner weten precies wat de user story inhoudt en waarop deze wordt beoordeeld met testen. Dit is geformuleerd in de acceptatiecriteria en de definition of done.

Product backlog

Je hebt ze vast wel eens gezien binnen jullie bedrijf, een andere afdeling of bij een digitale partner: een muur vol post-its. User stories schrijf je op post-its (Afb 1) of op de digitale variant ervan in een tool als Jira (afb 2).

De (digitale) post-it met je user story plaats je op de product backlog waar het gehele team ze kan zien (afb 3). De product backlog bestaat uit een lijst met items (de user stories) die uitgevoerd moeten worden tijdens de ontwikkeling van het product.

backlog jira
Afbeelding 3

Vervolgens bepaalt de product owner – in overleg met het development team – welke user stories van de backlog de meeste prioriteit hebben en opgepakt moeten worden. Hierbij verplaatst de product owner een user story van de backlog naar een sprint wanneer er gewerkt wordt met scrum of de “nog te doen” kolom op een Kanban bord.

Hierbij houdt hij scherp alle belangen in de gaten. Hoeveel tijd kost het om het te ontwikkelen? Wat voegt het toe voor de gebruikers? Op deze manier ga je kritisch om met de beschikbare ontwikkeltijd.

Tijdens het ontwikkelen en testen van het team ontstaat er iets magisch: voortschrijdend inzicht. Hieruit komen bijna altijd nieuwe functionaliteiten of verbeteringen die het product beter maken en komen ook op de product backlog te staan. Best practice is dat deze nieuwe user stories te allen tijde toegevoegd worden aan de product backlog. Zodat de product owner opnieuw kritisch kan kijken welke user stories de meeste waarde toevoegen en de hoogste prioriteit krijgen. De product owner houdt daarmee het overzicht en zorgt ervoor dat er efficiënt wordt omgesprongen met de schaarse ontwikkelcapaciteit. Uiteraard doet een product owner dat niet volledig uit zijn hoofd. En zoals we een paar alinea’s hiervoor beschreven zie je dat er in de praktijk op twee manieren gewerkt wordt: de fysieke variant met echte post-its, maar veel vaker met een gebruiksvriendelijke software tool als Jira waarmee het bijhouden van je backlog, sprintplanning of kanban bord kinderspel wordt.

Structuur aanbrengen bij user stories

User stories kunnen in verschillende detailniveaus worden beschreven. Bijvoorbeeld bij het opzetten van een nieuw project schrijf je diverse user stories, die je vervolgens in tientallen kleinere user stories vertaalt – binnen Jira heten dit subtaken en zijn ze gekoppeld aan een user story – om het behapbaar te maken. Ook kan het zijn dat je meerdere grotere user stories hebt die allemaal bijdragen aan één en dezelfde nieuwe functie of aanpassing, dan wordt zo’n grote user story ook wel ‘Epic’ genoemd. Door gedetailleerde user stories te koppelen aan Epics blijft je project overzichtelijk en kun je de werkzaamheden opdelen en verdelen over meerdere sprints in het geval van scrum of gefaseerd oppakken over een periode bij Kanban.

Kortom: door je eisen en wensen op te delen in user stories heb je een goed idee van wat er ontwikkeld moet worden, is het mogelijk een goede tijdsinschatting te maken en is de product owner in staat om samen met het team een realistische planning te maken.

Pragmatische partner voor jouw digitale uitdagingen?

Gillz ontwikkelt al 13 jaar op een pragmatische manier software, nog voordat scrum en kanban dé standaard in de softwareontwikkeling was. Sparren over welke digitale uitdagingen jullie ’s nachts wakker houden?


Bob van der Panne - Commericeel Directeur
Meer weten?

Sparren over de mogelijkheden of een kostenindicatie? Mail of bel direct Bob van der Panne.