Iedereen spreekt zijn eigen taal. IT-ers hebben hun eigen jargon, maar vooral hun eigen taal en de mensen, die met nieuwe ideeën komen (niet-ITers of "de business") lijken wel een compleet andere taal te spreken. Dit heeft naar mijn idee voornamelijk te maken met de context, waar deze groepen zich in bewegen. Daardoor worden IT-taal, business-taal en een gemeenschappelijke taal (zoals normaal Nederlands) door elkaar gebruikt en met elkaar verward.

Veel user stories worden niet in de context gezet, waarin ze thuishoren.
De context is dan de overkoepelende functionaliteit, meestal in de vorm van een Feature of Epic.
Of het is in de context geschreven, van een business analist, die aannames doet, dat de ontwikkelteams snappen wat hij bedoelt, omdat zijn directe collega's dat ook snappen.
En wat voor titel hebben die dan? Vaak nog een klinische titel aangevuld met de standaard tekst: "Als een <soort gebruiker>, wil ik <een doel bereiken> zodat <klantwaarde>".

Bovenstaande helpt natuurlijk als user stories nu nog geschreven worden in het formaat "Maak workflow voor reactie naar Klant", maar het is maar een klein onderdeel van de reis naar een product backlog en roadmap, die door iedereen begrepen wordt.

Als Product owner is het jouw verantwoordelijkheid, dat iedereen hetzelfde beeld heeft over hoe een bepaalde functionaliteit eruit moet zien. Dan is het wel belangrijk, dat iedereen dezelfde taal spreekt.

De enige taal, die alle groepen spreken is de taal zonder jargon en specifieke termen.

Probeer het eens met het vertellen van een verhaal, hoe jouw gebruiker jouw product ervaart.

Ben je ooit weleens bij een sprint review geweest (of is dit jouw eigen sprint review?), waar allemaal verschillende "user stories" werden gedemonstreerd? Een rapportje hier, een nieuw scherm voor een manager daar en in compleet andere functionaliteit nog eens een invoerscherm.

Hoe veel heb je daarvan meegekregen? (In ieder geval, dat dit zo'n review was)

Bedenk nu eens, wat er gebeurd was in diezelfde review, als die drie user stories met elkaar te maken hadden en een echt verhaal konden vertellen:

1. De klant belt klantenservice.
2. De klant krijgt een bericht, dat de wachttijd lang is, maar dat de optie er is om teruggebeld te worden.
3. De klant wordt snel teruggebeld door klantenservice.

Hier hebben jouw toehoorders in een sprint review een duidelijk beeld en snappen wat er gebeurt.
Als je dit ook als verhaal kunt vertellen, voordat er iets gebouwd is, kan het development team meer gericht vragen stellen, want hun scope heeft focus en het team snapt veel beter wat er verwacht wordt, omdat de context helderder wordt.

Het is alleen wel heel klinisch, want hier wordt alleen verteld wat de nieuwe functionaliteit doet en je kunt wel vertellen, dat die de klant helpt, maar ook dat is alleen informatie.

Bedenk nu eens, dat jouw intro voor deze user story flow een verhaal is, waarbij je de staat waarin de klant zich bevindt beschrijft. Nu is diezelfde sprintreview niet meer een aantal user stories, maar is het een verhaal geworden, waar het ontwikkelteam, maar ook de stakeholders een goed idee krijgen, wat het verhaal is.

Als je bij het begin van het ontwikkelproces al begint met het verhaal van jouw klant, en dat verhaal door de hele ontwikkelcyclus meeneemt, dan wordt de presentatie tijdens de sprint review niet alleen een prettige aangelegenheid in plaats van een klinisch proces, maar herkent iedereen dit verhaal ook, want ze hebben het al eerder gehoord en krijgen nu de uitwerking ervan te zien.

Tips voor betere User Stories

4 Tips om jouw verhaal duidelijker over te laten komen bij alle betrokkenen:
1. Gebruik een story board om het verhaal ook visueel te ondersteunen. Sommige mensen zijn gewoon meer visueel ingesteld en door een story board te maken (een soort stripverhaal) neem je meer mensen mee in jouw verhaal.
2. Gebruik story mapping om jouw verhaal samen met stakeholders en ontwikkelaars te ontwikkelen en neem hen mee in jouw verhaal.
De bekende “Vertel me, laat het me zien, neem me mee” - quote
3. Gebruik echte gebruikers om je verhaal te vertellen.
Een echte gebruiker, die zijn of haar wens komt vertellen in een story mapping sessie of in de demo, hoe cool is dat?
Als dat niet lukt, probeer dan gebruik te maken van persona’s om je luisteraar meer mee te laten leven met de gebruiker.
4. Herhaal het verhaal. Als het een goed verhaal is, dan verveelt het niet en dan gaat iedereen er in mee.
Herhaling is nog steeds de kracht van reclame.

Voor meer informatie, kijk eens hier:
http://www.thestoryconnection.nl/Over-storytelling/Wat-is-storytelling-Wat-is-een-verhaal
http://www.romanpichler.com/

Alex Roos, Agile coach/ Scrum master