Als je je bezighoudt met softwareontwikkeling, heb je vast wel eens van user stories gehoord. Misschien schrijft u ze zelfs als manager. Of misschien bent u een klant en wil uw software-ontwikkelaar dat u feature-verzoeken als user stories formuleert.

In dit bericht vindt u alles wat u ooit wilde weten over user stories.

Wat is een user story in software-ontwikkeling?

Een user story is een formaat voor het framen van software features en/of requirements. Zoals het “gebruiker” deel suggereert, zijn user stories geschreven in de eerste persoon enkelvoud en beschrijven een functie zoals het wordt waargenomen door de gebruiker van de app.

Een typische user story volgt deze structuur (als we het hebben over het Agile ontwikkelingsproces):

Als een,
Ik wil,
Zo dat .

Het eerste deel (als een…) specificeert de rol van de gebruiker in de toepassing, die normaal wordt geassocieerd met wat men daar mag doen.

Het tweede deel (de functie) wijst op het stukje functionaliteit dat in dit geval wordt gebruikt.

Het derde deel (het gewenste resultaat) is de waarde die de gebruiker uit de functie wil halen. Hier volgen enkele voorbeelden.

Voorbeeld 1

Als geregistreerde gebruiker,
wil ik een melding krijgen wanneer een vriend naar een evenement in de buurt gaat
Zodat ik op het nieuws kan reageren of mee kan doen met het evenement.

Voorbeeld 2

Als berijder,
Ik wil 10% korting krijgen op elke 10e rit
Zodat ik word beloond voor het consequent geld uitgeven aan de dienst.

Er zijn goede redenen voor dit soort structuren. Wanneer product/project managers te maken hebben met software-eisen die uit verschillende bronnen komen, is het voor hen soms moeilijk om uniformiteit te bereiken. Het kan ook onduidelijk zijn op welke categorie gebruikers de functie betrekking heeft of waar de bedrijfswaarde ligt. Het user story format helpt bij het vastleggen van deze kritische details.

Approaches to Composing User Stories

User stories kunnen op verschillende manieren worden geschreven, afhankelijk van wie er mee gaat werken.

The Gherkin Way

Gherkin is een plain-text taal die gedrag beschrijft zonder de implementatie te specificeren. Hier volgt een eenvoudig voorbeeld van de syntaxis van Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Zoals je misschien al hebt gemerkt, definieert inspringen de structuur in Gherkin. De basisparameters zijn Gegeven/Wanneer/Dan, en deze kunnen indien nodig worden aangevuld met meerdere En’s. De syntax gaat echter verder dan deze basis parameters. Als je echt vastbesloten bent om Gherkin onder de knie te krijgen, is hier een leuke tutorial.

Hoewel Gherkin misschien niet de beste keuze is bij het verzamelen van de eerste requirements voor het project, kan het wel nuttig zijn (vooral voor het QA team) bij het verder ontwikkelen van user stories. User stories geschreven in Gherkin zijn eenvoudig om te zetten naar test cases.

The Agile Way

Veel Agile project management applicaties bieden een functionaliteit voor het invoeren van user stories. We hebben bijvoorbeeld de Taiga app gebruikt op een aantal van onze interne projecten. Het helpt je bij het organiseren van werk rond user stories die kunnen worden opgesplitst in individuele taken in de backlog.

Bron: Taiga.io interface

Als je erover nadenkt, is het heel logisch om user stories als backlog-items te hebben en vervolgens meerdere taken aan één user story toe te voegen. Waarom? Omdat, laten we zeggen, je hebt één functie (=user story) en drie mensen die eraan werken; je hebt aparte taken nodig voor die mensen. Je hebt een ontwerper nodig om de interface te ontwerpen, een HTML/JavaScript programmeur om de interface te programmeren, en de DevOps om de interface in productie te nemen.

Andere tools zoals Pivotal Tracker (dat het concept van “epics” introduceert om gerelateerde stories te groeperen) laten je ook stories maken die van verschillende types kunnen zijn: Features, Chores, Bugs of Releases.

Bron: PivotalTracker.com

Afgezien van de verschillende benaderingen die door verschillende bedrijven worden gebruikt, vergeet niet dat er een eenvoudige en ongecompliceerde manier is om user stories te formuleren – voorbeelden daarvan zag je aan het begin van deze post.

Wie moet User Stories schrijven?

Dus, wiens verantwoordelijkheid is het om user stories te schrijven? Nou, het hangt ervan af. Als uw team heeft afgesproken om functies vast te leggen in de vorm van user stories, is het zeer waarschijnlijk dat ze afkomstig zijn van de aandeelhouders via de Product Owner. Dus, kan het de PO die daadwerkelijk pen ze neer.

Het kan ook een Project Manager of een QA die ook kan werken met de klant om functies en eisen te bespreken. Of, misschien bent u een 15-persoons startup en bent u de CEO, CTO, en CMO? In dat geval kunt u het goede voorbeeld geven en user stories gaan gebruiken om features te documenteren.

Velen in de IT hebben het ook over “user story development”, wat het proces is van het eerst registreren van high-level details (bijvoorbeeld beginnen met een eenvoudige lijst van features) en deze vervolgens ontwikkelen tot meer gedetailleerde stories door taken, scenario’s, enzovoort toe te voegen.

In Conclusie

Aan het eind van de dag helpt het formuleren van features in de vorm van user stories u om gefocust te blijven op de zakelijke doelstellingen. Het helpt je ook om de requirements compleet te maken. En, zoals gezegd, de precieze sjablonen/velden die je gebruikt kunnen verschillen, afhankelijk van de situatie.