User story is een belangrijke term als je werkt volgens de principes van Scrum. Wat een user story is? Zie het als een concrete en vereenvoudigde omschrijving van een specifieke functionaliteit die de eindgebruiker wil of moet hebben. User stories maken het werken aan software concreet. Het is een manier om de wensen van de gebruiker te vertalen naar concrete taken om aan te werken. We duiken hier graag dieper in voor je. Wat is een user story precies? Hoe ziet zo’n user story er in de praktijk uit?
Wat is een user story precies?
Een user story is een vereenvoudigde beschrijving van een taak om op te pakken die voortvloeit uit een wens van de eindgebruiker. Dus een functionaliteit waaraan je gaat werken zodat de gebruiker met de software kan wat hij ermee moet/wil kunnen.
Een user story is geen volledige omschrijving van wat je technisch gezien moet gaan ontwikkelen. Het is een korte beschrijving van wat de gebruiker wil of moet kunnen (ongeacht hoe je dat gaat realiseren).
Een user story begint altijd met “Als [rol persoon] wil ik…”, “Als [rol persoon] moet ik…” of “Als [rol persoon] zou ik willen…”. Bijvoorbeeld:
- “Als gebruiker moet ik kunnen inloggen in de app.”
- “Als gebruiker wil ik mijn wachtwoord kunnen wijzigen.”
- “Als gebruiker wil ik foto’s kunnen versturen via de app.”
- “Als gebruiker moet ik de app kunnen afsluiten.”
- “Als eigenaar van de app moet ik de gegevens van klanten kunnen bewaren op een veilige manier.”
User stories en Scrum
Bij het ontwikkelen van een app werken we volgens de Scrum-principes in sprints. Een sprint is een periode van twee weken waarin we diverse taken oppakken. Die taken zijn gebundeld in user stories.
In sprints pakken we user stories één voor één op om ze volledig te ontwikkelen en te testen. De Designers ontwerpen de functionaliteit, Development bouwt de functionaliteit en vervolgens wordt de functionaliteit getest en vandaaruit doorontwikkeld.
> Lees ook: Wat is Scrum precies?
De structuur van een user story
In het ideale geval is een user story als volgt opgebouwd:
- Als [rol van de persoon]…
- …wil ik/moet ik/zou ik willen… [beschrijving van wat ontwikkeld moet worden]…
- …zodat ik… [beschrijving van het doel van deze functionaliteit].
Daarmee is in één oogopslag duidelijk wat je ontwikkelt, voor wie je dat doet en welke waarde je daarmee levert. Degene die deze functionaliteit ontwikkelt of ontwerpt, heeft daardoor ook goed zicht op de randvoorwaarden.
User stories = gebruikerswensen
User stories staan dus voor de wensen die een specifieke gebruiker heeft als diegene de software gebruikt. Daarmee sluiten user stories goed aan op Design Thinking en Design-driven werken. Je gaat ontwerpen vanuit de wensen en behoeften van de gebruiker. Die wensen maak je concreet en daar baseer je op wat je qua werk gaat doen.
Denken in user stories helpt ook om gebruikerswensen te prioriteren. Stel: je ontwikkelt een app als WhatsApp. Dan is het cruciaal dat je in de app kunt inloggen en berichten kunt versturen. Een functie als foto’s kunnen versturen is een nice to have. Die functionaliteit kunnen we later oppakken en hoeft niet bij versie 1 al ontwikkeld te zijn.
Het Minimum Viable Product is de versie van het softwareproduct die alle noodzakelijke functionaliteiten heeft, maar nog niet de nice-to-haves. Dit is de eerste versie die live gaat in de app stores. Daar komt vervolgens feedback op. Voor versie 2 nemen we zowel de nice-to-haves mee die nog niet zijn opgepakt als de wensen van de klant en van de gebruiker die bij het testen naar voren komen.
Voorbeelden van user stories
Je weet nu ongeveer wat een user story is. Laten we het nog concreter maken. Stel: je gaat een app ontwikkelen waarmee patiënten hun medicatie kunnen bijhouden. Voorbeelden van user stories zijn dan:
- “Als gebruiker moet ik kunnen inloggen in de app.”
- “Als gebruiker moet ik kunnen invullen in de app welke medicatie ik vandaag heb genomen.”
- “Als gebruiker moet ik een overzicht kunnen krijgen van de medicatie (en de hoeveelheden daarvan) die ik de afgelopen maand heb genomen.”
- “Als gebruiker wil ik via de app een bericht kunnen sturen naar mijn zorgverlener.”
- “Als gebruiker wil ik een melding krijgen als ik medicatie slik die ik niet samen mag innemen.”
- “Als gebruiker zou ik willen dat ik in in de app bijwerkingen van de medicatie kan teruglezen.”
- “Als zorgverlener wil ik via de app vragen van patiënten kunnen beantwoorden.”
User stories moeten klein en behapbaar genoeg zijn om in één keer op te pakken en op te leveren. Een grote user story noem je een Epic. Een Epic splits je op in kleinere user stories, die niet te groot zijn om in één sprint op te pakken.
> Lees ook: Een app ontwikkelen, hoe gaat dat in zijn werk?
Wie bepaalt wat de user stories zijn?
Omdat user stories draaien om de wensen van de eindgebruiker, moet je de wensen van de eindgebruiker (en van de opdrachtgever) als uitgangspunt nemen. Meestal is de Product Owner degene die de user stories vaststelt door eerst in gesprek te gaan met de opdrachtgever en/of eindgebruiker. De Product Owner zet de user stories vervolgens op de Product Backlog.
De mensen die aan het project werken (Developers, Designers en Testers) pakken steeds een user story op die in de backlog staat. Die werken ze uit en leveren ze uiteindelijk op.
Samengevat: een user story is een stukje waarde
Je moet het zo zien dat elke user story een stukje waarde levert voor de eindgebruiker. Hij kan daardoor net iets meer met de software van wat hij moet, wil of zou willen kunnen. Het doel van een user story is altijd om waarde te leveren voor de eindgebruiker. Oftewel: je wilt iets maken wat bijdraagt aan een oplossing voor het probleem van de eindgebruiker.
Uiteraard kun je vaak niet in één keer het hele probleem oplossen. Wel kun je in user stories stukjes van het probleem aanpakken en daarmee steeds een klein beetje waarde leveren. Door de user stories te prioriteren, kun je beginnen met de user stories die de meeste waarde bieden.
