Veel user stories zijn geen user stories

We houden van user stories, omdat ze de gebruiker centraal stellen in de ontwikkelcyclus. In veel projecten worden user stories echter niet gebruikt zoals ze bedoeld zijn. We onderscheiden nog twee andere story types. Als je ze alle 3 correct gebruikt, verbetert dat niet alleen je projectresultaten, maar ook je proces.

Naast user stories maken we gebruik van business stories en technische stories.

Gebruikersverhalen

Als je bezig bent met digitale productontwikkeling, dan weet je van gebruikersverhalen. Het zijn verklaringen van een functie voor een specifieke gebruikersrol om een bepaald doel te bereiken. En ze worden vaak geschreven als:

Als <gebruikersrol> wil ik <activiteit of taak> om <gebruikerswaarde> te bereiken.

User stories draaien om daadwerkelijke gebruikerstaken en zijn gericht op het leveren van gebruikerswaarde. Deze gebruikersverhalen moeten worden gebouwd en gevalideerd met echte gebruikers.

Zakelijke verhalen

“In de backoffice ontvangt {company} alleen gevalideerde sollicitaties.” Dit real-life verhaal (ten onrechte geponeerd als user story) is belangrijk voor de business en niet per se voor de gebruiker. Zolang zijn aanvraag wordt verwerkt, maakt het de gebruiker waarschijnlijk niet uit hoe dat gebeurt.

Bedrijfsverhalen zijn gericht op het bedrijf met als doel het leveren van bedrijfswaarde. Zakelijke verhalen moeten worden geschreven en gevalideerd met de relevante zakelijke belanghebbenden, die goed geïnformeerd zijn over het onderwerp van het verhaal. Op die manier kunnen alle belangrijke details worden blootgelegd die nodig zijn voor het succesvolle ontwerp en de ontwikkeling van het product.

Als <stakeholder> wil ik <vereiste> om <business value> te realiseren.

Technische verhalen

Een backlog bestaat uit user stories. We vinden er echter vaak items in die ontwikkelaars moeten doen op weg naar het voltooien van de gebruikersverhalen. En als ze niet in de backlog staan, kun je er niet aan werken. Dat leidt tot “user stories” zoals:

“Als bewoner wil ik via de cloud communiceren met een consultant, zodat ik weet dat mijn uitwisseling op een veilige manier verloopt”. Uiteraard is de wens om met een adviseur te communiceren terecht. Dit verhaal omvat echter de middelen (de cloud), waar de meeste gebruikers niets om geven of niet aan denken. En, aantoonbaar, hetzelfde geldt voor de beveiliging van een beurs.

Moeten we dat deel van het verhaal verwijderen? Natuurlijk niet. Als de aangewezen oplossing is om met een cloud te werken, dan moet dat onderdeel zijn van de backlog. Maar wees duidelijk en verstop het niet in een user story.

In veel teksten over het onderwerp wordt dit type user story vaak een “technical user story” genoemd. Als je erover nadenkt, betekent dat dat het woord "gebruiker" zijn betekenis heeft verloren in deze constructie. Bob Galen , die boeken schreef als "Agile Reflections" en "Scrum Product Ownership", definieert een technisch (gebruikers)verhaal als "... gericht op niet-functionele ondersteuning van een systeem".


Bob Galen over technische (gebruikers)verhalen
Bob geeft er de voorkeur aan om deze verhalen op te schrijven zonder te proberen ze in een zin van het type "gebruikersverhaal" te schrijven, maar eerder om "de behoefte (technisch) te kwantificeren, in duidelijk Engels met misschien een paar zinnen, en dan verder te gaan."

Het juiste product maken

Het maskeren van zakelijke en technische verhalen als gebruikersverhalen leidt tot verlies van de gebruiker uit het oog. Het zorgt ervoor dat aan alle zakelijke en technische vereisten wordt voldaan. Omdat elke gebruikersbehoefte in de context van dit ene product wordt geplaatst.

We zien vaak dat dat proces ook leidt tot veel aannames over gebruikers, gebaseerd op de kennis die mensen hebben van hun eigen product.

Dat is echter niet hoe gebruikers naar dingen kijken. Ze leven in een wereld waar het product slechts een onderdeel is van hun dagelijks leven. Ze gebruiken het product ook als onderdeel van een groter proces en ecosysteem en dat leidt tot andere eisen. Eisen die cruciaal kunnen zijn voor het juiste ontwerp van je product en die je uit het oog zou kunnen verliezen als je niet met 'pure' user stories werkt.

In een notendop

Voor business stories praat je met stakeholders. Voor technische verhalen praat je met architecten en ontwikkelaars. Voor user stories praat je met gebruikers.

Misschien vind je het ook leuk:

Een inleiding tot waardegedreven ontwerpen

Producentenwaarden verduidelijken: het geheim van waardevolle UX-projecten

Koperswaarden in het ontwerpproces: wanneer 'waarom' belangrijker is dan 'wat'

Upgraden van functiegedreven naar waardegedreven ontwikkeling

Angelique
Ben je geïnteresseerd in onze expertise?

Laten we samen een oplossing vinden!

Angelique Overbeek

Managing Director