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.
