Om je budget te bewaken en geen tijd te verliezen aan miscommunicaties is het belangrijk dat alle betrokkenen op dezelfde lijn zitten. Een belangrijk concept daarvoor in softwareontwikkeling is de user story: de formulering van een requirement vanuit het oogpunt van de eindgebruiker.

Een softwareproject kan complex zijn, met allerlei betrokkenen met ieder hun eigen rol en perspectief: opdrachtgevers, ontwerpers, investeerders, potentiële gebruikers, projectmanagers, developers, et cetera. Hoe faciliteer je strakke communicatie zodat iedereen met dezelfde visie te werk gaat? Een antwoord daarop is de user story.

Wanneer gebruik je user stories?

Bij het bouwen van een applicatie splits je het werk op in allerlei vereisten die één voor één worden gerealiseerd. Om ervoor te zorgen dat elke betrokkene de vereisten begrijpt, is de user story bedacht.

Hoe formuleer je een user story?

De specifieke, heldere formulering is de basis van een goede user story. Deze formulering bestaat uit de volgende opmaak:

Als [eindgebruiker] wil ik [functionaliteit], omdat [context].

De [eindgebruiker]

Je begint met de identificatie van de eindgebruiker, zo weet je meteen wie uiteindelijk baat heeft bij de ontwikkeling van een bepaalde vereiste. Het is belangrijk om die persoon te begrijpen, zodat de gebouwde functionaliteit aan zijn/haar wensen voldoet.

Een veelgebruikte techniek om de eindgebruiker begrijpelijk te maken, is de creatie van verschillende fictieve personages die je app gaan gebruiken. Bijvoorbeeld ‘Susan, 35 jaar, hoogopgeleid, getrouwd, heeft een dochter, werkt als docent, houdt van koken’. Als de user story dan begint met ‘Als Susan wil ik…’ is haar wens minder abstract, omdat je haar achtergrond begrijpt en je daarin kunt inleven.

De eindgebruiker hoeft niet per se een klant te zijn. De personificatie hiervan is volledig afhankelijk van wie een bepaald stuk functionaliteit uiteindelijk gaat gebruiken. De eindgebruiker kan bijvoorbeeld ook een collega of werknemer zijn, of een betrokken developer of de opdrachtgever zelf.

De [functionaliteit]

Het middelste deel van de user story is de concrete beschrijving van de vereiste functionaliteit. Moet er een knop worden gebouwd? Een invulveld? Een hele pagina? Et cetera. Door een heldere omschrijving van de functionaliteit verklein je de kans op miscommunicaties en blijft iedereen op dezelfde lijn. Bijvoorbeeld ‘Als Susan wil ik kunnen aanvinken dat ik geen kaas op mijn hamburger wil’.

De [context]

Ten slotte geef je context voor het verzoek. Zo begrijp je niet alleen wie de eindgebruiker is en wat deze wil, maar ook waarom hij/zij dat wil. Bijvoorbeeld: ‘Als Susan wil ik kunnen aanvinken dat ik geen kaas op mijn hamburger wil, omdat ik lactose-intolerant ben’. Wanneer vereiste functionaliteit complexer wordt, kan het voor betrokkenen onduidelijk zijn waarom die functionaliteit nodig is. Met de context neem je die onduidelijkheid weg.

Een belangrijk voordeel van de context-formulering is ook de mogelijkheid tot brainstorming over oplossingen. Normaliter heeft de opdrachtgever éérst context (een probleem) en bedenkt hij/zij daaruit nieuwe functionaliteit (de oplossing). Als je naast de oplossing ook het probleem aan je team communiceert, kan het zijn dat iemand in je team een betere of efficiëntere oplossing weet.

Door elke vereiste op deze manier te formuleren, zorg je ervoor dat de eindgebruiker het middelpunt van je visie blijft en dat elke betrokkene begrijpt welke functionaliteit met welke reden wordt geïmplementeerd.