Een user story is de kortste manier waarop iemand vertelt waarom hij/zij een product wil en wat hij ervan verwacht. User stories worden gebruikt bij het ontwikkelen van software of producten, maar ook steeds vaker op marketing-afdelingen: wat wil de klant? Behalve voor ontwikkeling zelf zijn ze ook waardevol voor de product-positionering en voor de productstory. #productstory #productpositionering.
Eerst maar even dat misverstand wegruimen: een user story is namelijk geen verhaal. User stories zijn eerder voorkeuren die uit verhalen van (interne) klanten of (interne) gebruikers zijn gefilterd. Het is de zakelijke informatie die achterblijft als je een verhaal in een zeef kiepert. Feitelijk kunnen ontwikkelteams niks zonder deze 'verhalen'. User stories zijn dan ook verplicht voor scrum-programma’s en andere agile toepassingen. Niet alleen in software development, maar in alle projectteams op alle afdelingen in elke organisatie. Wat te denken van marketing en sales?
Mini-stories
Een user story bestaat uit één zin. Niet meer. Voorbeeld uit de ICT: ‘Als gebruiker (rol) wil ik mijn klanten kunnen zoeken (wens, behoefte of waarde) op zowel de voornaam als op achternaam (specificatie).’ Maar er zullen per te ontwikkelen product uiteraard meerdere voorkeuren van (toekomstige) gebruikers verzameld worden. En dus ga je straks als ontwikkelaar, marketeer of salesmanager werken met meerdere user stories met een ranking.
Product owner in scrum-team
In agile-processen w.o. scrum, bewaakt de Product Owner (PO) de belangen van de (interne) klant. De PO vertegenwoordigt de interne of externe klant. Maar het zou natuurlijk te gek voor woorden zijn als de klantfocus alleen leidend zou zijn in agile processen. Dat moet in elk marketing- en salesteam leidend zijn. De interactie tussen scrum-teams, marketing en sales op basis van user stories is de manier waarop een commerciële organisatie zichzelf continu verbetert. Dan zet je namelijk letterlijk de klant centraal.
Klant-interviews en user stories
Hoe maak je user stories? De beste manier is om (toekomstige) klanten c.q. gebruikers te interviewen (kwalitatieve interviews) met vragen als: wat verwacht u van een ... ? Waar moet die volgens u aan voldoen? Wat vindt u belangrijk aan ... ? Hoe belangrijk vindt u X, Y, Z en waarom precies? Zorg er voor dat je voldoende mensen (toekomstige bezoekers, gebruikers, kopers, M/V, jong/ouder etc.) te spreken krijgt. Drie is te weinig, tien is beter en meer dan vijftig is niet nodig.
Gebruik klachten als referentie
Vergeet niet om de oogst te clusteren op gebruikersaspecten en die vervolgens ook weer te vergelijken met een analyse en clustering van de klachtenafdeling. Een klacht is een gratis advies. Maak daar gebruik van door te inventariseren of de user stories positief gaan inschieten op de klantbeleving.
Functionaliteit en user stories
De user stories vormen de belangrijkste manier waarop de gebruiker invloed heeft op de functionaliteit van het te ontwikkelen systeem of product. Maar je kunt wel meerdere user stories per product genereren. Daarvoor kijk je simpelweg naar de belangrijkste aspecten (wensen, waarden of functionaliteiten), bijvoorbeeld gebruikersgemak, veiligheid, kwaliteit en performance.
Scrum-teams en user stories
De producteigenaar sorteert de user stories op volgorde van belangrijkheid en splitst ze uit in taken die hij aan ontwikkelteams toewijst. Die gaan er in kortlopende deelsessies (zgn. ‘sprints’ in de scrum-methodiek van twee tot vier weken) mee aan de slag. Dat begint met een brainstorm van een dagdeel over de implicaties van de user stories voor het ontwerp. Aan het einde van de sessie beschikken scrum-teamleden over een sprintplan met concrete taken en -planning. Binnen het vooraf vastgestelde budget en tijd worden de deliverables ingedeeld in Need-to-have’s, Nice-to-have’s en de Not (Now)’s.
Tips voor user stories
Geef elk type gebruiker een eigen kleur post-its.
Laat gebruikers eerst gewoon vertellen; en probeer daarna pas in te zoomen op de specifieke gebruikerswensen.
Markeer als Product Owner de belangrijkste woorden per type gebruiker.
Onthoud dat de Product-Owner de baas is over de product-backlog en dus ook over de prioritering van de user stories.
Vergelijk de uitkomsten van de sessies met de geclusterde klachten over de afgelopen jaren.