Een goede basis voor gelukkige gebruikers: zo schrijf je een user story

Dit artikel is gepubliceerd op Frankwatching
Als je een nieuw systeem gaat ontwikkelen, zoals een website, DLWO (digitale leer- en werkomgeving) of zorgportaal, dan is daar een heel team van experts bij betrokken. Niet alleen de welbekende developers & designers, maar ook conceptontwikkelaars, architecten én informatie-analisten. Tot die laatste groep specialisten behoor ik.

Welke rol speelt de informatie-analist in een ontwikkeltraject?

Ik krijg vaak de vraag welke rol ons specialisme speelt in een ontwikkeltraject. Want wat dóen informatie-analisten nu eigenlijk? Stel, een bestuurder van een onderwijsinstelling wil een DLWO voor zijn studenten. Onze conceptontwikkelaars maken op basis van zijn vraag een concept, dat we aan de klant presenteren.

Maar de stap van concept naar ontwikkelen is veel te groot om in één keer te zetten. Het concept heeft namelijk nog te weinig details over de wensen van de eindgebruikers en mist antwoorden op belangrijke vragen. Ontwikkelaars kunnen dus nog niet aan de slag.

Daar komt de informatie-analist om de hoek kijken. Wij verzamelen een hoop informatie – van de klant, eindgebruikers en andere specialisten – en verwerken dat tot een document waarmee het ontwikkelproces wél van start kan gaan. Eén van de ‘tools’ die we daarvoor vaak gebruiken, is de user story.

In de spotlights: de user story

Een user story is in feite een klein verhaaltje waarin kort wordt omschreven waar een specifieke functionaliteit aan moet voldoen. User stories vertalen het concept voor een systeem tot een pakket aan wensen en behoeftes. Daarmee kan een team van ontwikkelaars aan de slag met het bouwen van losse functionaliteiten.

User stories worden in moderne agile-trajecten vaak in plaats van een functioneel ontwerp gemaakt. Waarom is dat eigenlijk zo?

• User stories zijn klein en overzichtelijk en ze voegen ieder waarde toe. Een user story gaat maar over één functionaliteit.
• User stories zijn bovendien onafhankelijk van elkaar, dus ontwikkelteams kunnen los van elkaar één specifieke functionaliteit ontwikkelen. Bij een functioneel ontwerp wordt alles in één keer, allemaal achter elkaar gebouwd.
• Omdat ze zo klein zijn, zie je snel resultaat en kun je snel terugkoppelen en bijsturen.
• Je kunt goed inschatten hoeveel tijd het kost om een user story tot functionaliteit te ontwikkelen en daarmee een betere planning maken.
• De klant kan bij elke user story en bij elk stukje functionaliteit terugkoppeling geven. Zo is de klant veel meer betrokken bij het eindresultaat.

Hoe schrijf je een goede user story?

In de ideale wereld zou de klant, de product owner, user stories schrijven. Hij weet immers het beste welke wensen er binnen de organisatie en bij de eigen klanten of gebruikers zijn. Maar in de praktijk wordt het vaak door de informatie-analist gedaan. Meestal omdat de product owner er geen tijd voor heeft, of niet goed weet hoe het moet. Terwijl het schrijven van een goede user story niet moeilijk hoeft te zijn.

Laten we beginnen met uitleggen wat een user story precies is. Een goede user story:

• is een korte, bondige beschrijving van een functionele wens van een gebruiker;
• is in gebruikerstaal geschreven, bij voorkeur door de product owner;
• heeft altijd toegevoegde waarde voor de gebruiker;
• is een discussie-stuk (en geen contract).

Dat laatste punt is erg belangrijk. Een user story is niet zo gedetailleerd dat er vastgelegd is wat er precies gemaakt moet worden. Een goede user story biedt voldoende informatie om over te discussiëren, zodat samen gezocht kan worden naar de beste oplossing om functioneel aan de wens van de gebruiker te voldoen.

De componenten van een user story: wie, wat en waarom?

Een goede user story bestaat verder uit een aantal componenten:

• het heeft een pakkende, goed beschrijvende titel, zodat iedereen weet over welk ‘verhaal’ het gaat als erover gepraat wordt;
• het kent duidelijke acceptatie-criteria, op basis waarvan je na afloop kunt testen of de vraag goed ingevuld is;
• het vertelt altijd wie iets wil, wat deze persoon wil bereiken en waarom hij of zij dat wil. Het antwoord op de waarom-vraag geeft de toegevoegde waarde voor de gebruiker aan.

Een voorbeeld

Je ziet dat deze user story een duidelijke titel heeft. Daarna worden de wie-, wat- en waarom-vraag beantwoord. De student [wie] wil zijn lesrooster van vandaag inzien [wat] zodat hij weet welke lessen hij op welk moment heeft [waarom/waarde]. Tot slot zie je de acceptatiecriteria, die bepalen of de uiteindelijke functionaliteit aan de eisen voldoet. Dit alles past op een post-it. Als dat niet zo is, dan is je user story te groot.

Template voor het schrijven van een user story

Aan dit voorbeeld kun je direct een goed template voor de omschrijving van een user story afleiden:

Als [wie] wil ik [wat] zodat ik [waarom].

Een aantal tips bij dit template:

• Wees altijd zo specifiek mogelijk als je de [wie] omschrijft. Gebruik geen algemene termen zoals ‘gebruiker’. Je moet weten welke ‘persona’ of groep gebruikers precies de functionele wens heeft.
• Gebruik werkwoorden als je de [wat] omschrijft. Dat geeft namelijk aan wat de gebruiker wil bereiken. Dus niet “ik wil een overzicht”, maar “ik wil een overzicht inzien”.
• Wat vaak gebeurt, is dat er niet omschreven wordt ‘waarom’ een bepaalde gebruiker iets wil bereiken, maar ‘hoe’ hij dat wil doen. Probeer niet in die valkuil te stappen. Het beantwoorden van de hoe-vraag laat je namelijk juist aan de ontwikkelaars over.
• Gebruik geen jargon, tenzij daar afspraken over gemaakt zijn. Het kan anders snel leiden tot interpretatieverschillen.

INVESTeer in je user stories

Wil je zeker weten dat je goede user stories hebt geschreven? Haal ze dan langs deze INVEST-checklist:

Is it Independent?
Zorg dat je user stories onafhankelijk zijn van andere stories, zo kan de product owner (de klant) prioriteiten stellen.

Is it Negotiable?
User stories moeten niet te gedetailleerd zijn. Ontwikkelaars moeten de vrijheid krijgen om zelf in te vullen hoe een functionele wens vorm krijgt.

Is it Valuable?
De functionaliteit moet uiteindelijk een waardevolle bijdrage leveren voor de gebruiker. Die waarde wordt door de product owner bepaald. De meest waardevolle functionaliteiten worden als eerste ontwikkeld.

Is it Estimable?
Kun je inschatten hoe veel tijd en werk het ongeveer kost om de functionaliteit te ontwikkelen en is alle kennis in huis?

Is it Small enough?
Is de user story klein genoeg?  Past ie op één post-it en beschrijft ie maar één functionaliteit? Hij moet ook niet te klein zijn. Als ‘ie te weinig waarde heeft, kun je kleine user stories beter bundelen tot een grotere. Vuistregel: als het langer duurt dan een dag of twee om een story te ontwikkelen tot functionaliteit, dan is ie te groot. Duurt het een korter dan een uur, dan is ie te klein.

Is it Testable?
Heb je de goede acceptatiecriteria omschreven bij de user story, waardoor je kunt bepalen of de functionaliteit straks aan de eisen voldoet?

Een goede basis voor gelukkige gebruikers

Kun je op alle bovenstaande vragen ‘ja’ antwoorden; dan vormt je user story een goede basis voor de ontwikkelaars om aan de slag te gaan. En het lijkt misschien klein en daarmee futiel, zo’n kort verhaaltje op een geeltje. Maar als je investeert in het schrijven van goede user stories, levert dat uiteindelijk een systeem op waar al je gebruikers gelukkig mee zijn, en dat iedere user met plezier gebruikt. En dat doel, dat hebben we allemaal voor ogen.

Wil je meer weten? Klik hier voor het Webinar User Stories.

Twan van Vlerken
Informatie Analist