3 user story-missers & hoe je ze voorkomt

User stories vormen het startpunt van ieder agile ontwikkeltraject. Ze geven het ontwikkelteam richting en vormen het fundament voor de te bouwen functionaliteiten. Maar een goede user story schrijven is nog niet zo makkelijk. Wat zijn de meest gemaakte fouten? En hoe voorkom je ze?

Wat is een user story?

User stories zijn korte verhalen waarin niet de functionaliteiten, maar de behoeften en wensen van de gebruiker centraal staan. Ze vertalen in feite het concept voor een systeem tot een pakket aan wensen en behoeftes. Een van mijn collega’s schreef hier al eens eerder een interessant artikel over. Hierin lees je waar een goede user story precies aan moet voldoen en hoe je zo’n verhaal schrijft.

Voor het schrijven van een user story kun je het beste het volgende model gebruiken:

Omdat ik veel voor onderwijsinstellingen werk, volgt hier een heel simpel voorbeeld voor een studentenportaal:
“Als student wil ik mijn rooster kunnen inzien, zodat ik weet welke lessen ik vandaag heb.”

Het gaat vaak fout: 3 user story-missers

Tot zover klinkt het allemaal heel eenvoudig. Toch gaat er bij het schrijven van een user story nog heel vaak iets mis. De meest gemaakte fouten (en hoe jij ze in de toekomst voorkomt) lees je hieronder.

Fout #1: de gebruiker vergeten

User story. De term zelf maakt duidelijk hoe belangrijk de gebruiker in het geheel is. Het lijkt haast onmogelijk om de essentie in je verhaal te vergeten, maar toch gebeurt het geregeld. Vaak is dit te wijten aan het feit dat een story meestal onder tijdsdruk wordt geschreven.

Een voorbeeld:
“Als gebruiker wil ik kunnen zoeken door de hele website, zodat ik relevante informatie eenvoudig kan vinden.”

Zie daar, je bent vergeten te omschrijven wie de gebruiker precies is. De ene user is de andere niet. Ze hebben allemaal hun eigen behoeften en skills. Door de gebruiker niet bij naam te noemen, zul je nooit haar standpunt kunnen innemen. Pas als je je in de specifieke gebruikersgroep verplaatst, kun je de toegevoegde waarde van de wens van deze groep bepalen. Iedere functionaliteit moet waarde voor de gebruiker in kwestie toevoegen. Het is onmogelijk om te controleren of dat zo is, als je de gebruiker niet concreet voor ogen hebt.

Pas als je je verplaatst in een specifieke gebruikersgroep, kun je de toegevoegde waarde van de wens van deze groep bepalen.

Hoe voorkom je deze fout?

Het antwoord is simpel: door je bij het formuleren van een story altijd te verplaatsen in de gebruiker. Wie is de user? Om welke persona gaat het? Wat voegt deze functionaliteit voor deze specifieke user toe? Gebruik bijvoeglijke naamwoorden om de gebruiker nog meer te specificeren. En neem als het even kan ook mee welke rol er in het systeem aan de functionaliteit gekoppeld moet worden, zodat de user straks ook bij deze functionaliteit kan.

Fout #2: de ‘waarom’ vergeten of niet goed uitwerken

Het goed formuleren van de ‘waarom’ in de user story is het lastigste deel. Dit belangrijke deel van het verhaal geeft context aan wat je moet gaan bouwen. De ‘waarom’ geeft je inzicht in waarom de functionaliteit nodig is en geeft – hoe kort ook – de broodnodige diepgang aan de user story. De ergste fout die je kunt maken, is de ‘waarom’ uit de user story weglaten. Maar het is nog niet zo makkelijk om een ‘goede waarom’ te omschrijven.

Als de user story als volgt luidt: “Als medewerker wil ik een overzicht van alle feestdagen, zodat ik meteen vrij kan vragen voor de dagen eromheen”, dan kom je tot de conclusie dat er in het feestdagenoverzicht een link moet komen naar de verlofaanvraagmodule. De ‘waarom’ geeft hier inzicht in wat de toegevoegde waarde is van zo’n overzicht. Als je de ‘waarom’ niet (goed) weet, dan begrijp je wellicht niet goed de reden om iets te bouwen en maak je misschien wel iets dat niet waardevol of relevant is.

Hoe voorkom je deze fout?

Een story formuleer je aan de hand van gesprekken met de gebruikers zelf. Als je vraagt naar hun behoeften en wensen moet je goed doorvragen naar de achterliggende redenen. Mensen gaan al gauw in technische oplossingen denken. Ze beantwoorden dan de hoe-vraag (hoe moet dit eruit gaan zien?) in plaats van de waarom-vraag (waarom heb je dit nodig?). Een tip om dit te voorkomen, is door je story anders te formuleren. In plaats van de gebruiker voorop, zet je de ‘waarom’ voorop.

Fout #3: de productvisie vergeten

Ieder project moet beginnen met een projectvisie; een document waarin je vastlegt wie de persona’s zijn, wat hun algemene behoeftes zijn en wat de belangrijkste functionaliteiten zijn die je nodig hebt.

Maar ook: wat zijn concurrerende producten, wat is het budget en hoeveel tijd is er beschikbaar is om het systeem te ontwikkelen? Kortom: een productvisie biedt randvoorwaarden, schept een kader en geeft richting. Alle user stories die je schrijft moeten uiteindelijk in dienst staan van die visie.

Voorbeeld van een productvisie

Een quote uit een projectvisie kan bijvoorbeeld zijn:
“We willen een aantrekkelijke, toegankelijke, vraaggestuurde website bouwen, waarmee potentiële studenten uit binnen- en buitenland geïnformeerd en geënthousiasmeerd worden. Het doel is dat het aantal inschrijvingen zal toenemen. De website biedt alle informatie en mogelijkheden om je direct in te schrijven voor informatie, evenement of studie.”

Als voor de website, zoals in het voorbeeld hierboven, studentenwerving centraal staat, dan wil je het zoeken in het curriculum waarschijnlijk prominent laten zien, zodat potentiële studenten snel kunnen zien wat er allemaal aangeboden wordt.

De visie is niet helder bij het ontwikkelteam

Regelmatig is die visie echter niet goed omschreven. Nog vaker is de visie bij het ontwikkelteam niet helder of zelfs onbekend. Developers denken misschien dat ze geen visie nodig hebben bij het bouwen van een website voor een onderwijsinstelling, want ze hebben al zo vaak zo’n website gebouwd. Been there, done that. Maar een visie kan voor iedere website verschillen, en bovendien heel specifiek zijn.

Gaat het om een wervende website of juist een informerende? Wat is het doel? Soms ligt er een hele urgente kwestie aan ten grondslag, bijvoorbeeld een te lage betrokkenheid van medewerkers of studenten. Of het is juist heel praktisch: ze willen dat gebruikers dankzij het systeem efficiënter en sneller hun werk kunnen doen, om zo geld en tijd te besparen.

Hoe voorkom je deze fout?

Je voorkomt deze fout ten eerste door een heldere productvisie uit te werken. Maar ook door er voor te zorgen dat de productvisie voortdurend leeft bij iedereen die aan het project werkt. Haal deze er opnieuw bij als je in de sprintplanning vastloopt en even niet meer weet wat de belangrijkste user story is om op te pakken. De visie kan je helpen om te prioriteren en te toetsen of je aan de juiste dingen werkt.

‘Easy to understand, hard to master’

Als je de valkuilen in dit artikel leest, dan denk je wellicht: ach joh, hoe moeilijk kan het zijn? Gewoon even goed opletten! Maar ze zijn zó voor de hand liggend, dat het verraderlijk is. User stories zijn, zoals het Scrummanifest zegt, ‘easy to understand, but hard to master’. En natuurlijk staan fantastisch geformuleerde stories niet garant voor een succesvol project. Uiteindelijk zijn ze ook geen doel op zich, maar een middel om dat doel te bereiken; een systeem waar iedere gebruiker écht iets aan heeft.