Wat is een user story? En hoe wordt dat toegepast tijdens de ontwikkeling van een nieuwe app of applicatie? Dat zijn twee veel gestelde vragen tijdens het ontwikkeltraject. In deze blog geven wij antwoord.
User stories zijn korte, eenvoudige beschrijvingen van een eigenschap (feature) voor de nieuw te ontwikkelen applicatie. Deze eigenschappen worden opgesteld in overleg met de klant of eindgebruiker. User stories zijn één van de belangrijkste onderdelen binnen de Scrum-ontwikkelmethode. Op basis van een user story kunnen de developers en de 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].
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 handmatig hoef uit te voeren].
Eigenschappen van een user story
Uit het voorbeeld hierboven wordt duidelijk wat een mogelijke user story is. Maar welke eigenschappen bevat een goede user story? Dat 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 gedefinieerd. 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.
Verschillende niveaus van user stories
User stories kunnen in verschillende detailniveaus worden beschreven. Bijvoorbeeld bij het opzetten van een nieuw project schrijf je diverse user stories. Die vertaal je vervolgens in tientallen kleinere user stories (subtaken) 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 Epic’s 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.
Product backlog
User stories schrijf je op post-its of in een digitale tool zoals Jira. De (digitale) post-it met je user story plaats je op de product backlog waar het gehele team ze kan zien. De product backlog bestaat uit een lijst met items (de user stories) die uitgevoerd moeten worden tijdens de ontwikkeling van het product.
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.
Voortschrijdend inzicht
Tijdens het ontwikkelen en testen ontstaat er iets magisch: voortschrijdend inzicht. Hieruit komen bijna altijd nieuwe functionaliteiten of productverbeteringen 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.
Kortom: door je eisen en wensen op te delen in user stories, heeft het ontwikkelteam een goed idee van wat er ontwikkeld moet worden, kunnen zij een goede tijdsinschatting maken en kan er een realistische planning gemaakt worden.