User stories

Van de drie bekendste gestructureerde ontwikkelvormen, waterval, iteratief en Agile/scrum, is de laatste inmiddels het meest in trek, inclusief daarvan afgeleide vormen zoals Disciplined Agile Delivery en Agile Unified Process. Scrum is een vorm waarbij communicatie belangrijker is dan documentatie, integraal werken belangrijker dan contractonderhandeling en iteratieve releases belangrijker dan gegarandeerd opgeleverde functionaliteit. Deze ontwikkelvorm vereist ook een aangepaste requirement vorm: de user story. Onderstaande artikel geeft overzicht wat user stories zijn, wat eigenschappen van user stories zijn, wat je bij een user story registreert en ten slotte hoe je het best user stories schrijf.

Wat is een user story

Een user story beschrijft een deel functionaliteit die waarde oplevert voor tenminste één van de stakeholders(gebruikers). Een user story bestaat uit drie onderdelen:
  1. Beschrijving van de user story, geschreven in de vorm: Ik (als een rol/gebruiker) wil (functie/actie) met als voordeel (doel/waarde voor rol/gebruiker)
  2. Discussie over de user story om de details boven tafel te krijgen
  3. Testdetails waarmee bepaalt wordt of de user story compleet is.

De drager van een user story is meestal een kleine kaart, bijv. een post-it note of een A5/6 kaartje. Daarover later meer. (Mike Cohn, 2004, User Stories Applied: For Agile Software Development). Mensen en hun onderlinge interactie boven processen and tools Werkende software boven allesomvattende documentatie Samenwerking met de klant boven contractonderhandelingen Inspelen op verandering boven het volgen van een plan

Wat zijn de eigenschappen van een goede user story?

Een user story is:

Acroniem ´INVEST´. Niet origineel, wel eenvoudig te onthouden (Wake, 2003, ).

Welke eisen worden aan een goede user story gesteld?

User stories zijn extern beschreven: een user stort beschrijft de gevraagde functie vanuit klantperspectief. Wat het systeem doet is een black box: dat bepaalt het ontwikkelteam. Hierop aansluitend: een user story is in de taal van de klant geschreven.

User stories beschrijft de gevraagde functionaliteit van alle stakeholders: het aantal stakeholders is snel groter dan je denkt. Voor een eenvoudige online hypotheekshop kwamen we uit op 21 gebruikers, waaronder 14 directe gebruikers (bijv. hypotheekadviseur) en 7 indirecte gebruikers (toezichthouder AFM).
NB zet altijd in om echte gebruikers van het systeem te krijgen en niet uitsluitend substitutie gebruikers, die toevallig tijd hebben. Daarmee voorkom je dat de user stories onvoldoende aansluiten bij kennis/ervaring van de echte gebruikers. Bijvoorbeeld neem in het geval van call center agents geen genoegen met uitsluitend input van trainers, functioneel beheerders of supervisors: al deze gebruikers zullen hun best doen om de juiste input te leveren, maar geen van deze rollen krijgt ooit een klant aan de lijn.

Een user story beschrijft end-to-end functionaliteit. Dus gebruik voor het vastleggen van een order:

En niet: Beschrijf het resultaat in de user story, zorg er voor dat het een gesloten user story wordt.
Bijvoorbeeld de user story “De functioneel beheerder kan aanbiedingen op de site aanpassen” voldoet prima tijdens het inventariseren van user stories, maar bij aanvang van de iteraties dient de omschrijving nauwkeuriger, bijvoorbeeld:
Het detailniveau van User Stories komt overeen met fase van proces. User stories dienen zowel globaal als gedetailleerd uitgewerkt te zijn: met de aanvang van een project zijn requirements globaal beschreven en wanneer user stories geselecteerd worden voor ontwikkeling, dienen de user stories tot in detail uitgewerkt te worden. Dit uitwerken gebeurt in overleg tussen Product owner en de rest van het (ontwikkel)team (Scrum sessie). De globale user stories hebben verschillende functies, waarvan er één is dat ontwikkelaars met het eindbeeld in hoofd ontwikkelen. Niet om dat eindbeeld direct te ontwikkelen, maar wel om daar in hun software rekening mee te houden.

Welke informatie bevat een user story kaart?

De user story kaart bevat naast de user story de volgende elementen:
  1. Niet-functionele eisen (optioneel)
  2. Aanvullende details/scenario's voor testen (vereist)
  3. Beperkingen/voorwaarden (optioneel)
  4. Story points of de capaciteit die nodig is user story te ontwikkelen (vereist)
  5. Prioriteit (vereist)
  6. verklarende illustratie(optioneel)
De onderdelen 1 t/m 3 worden op de achterkant van de kaart geplaatst om daarmee de voorkant van de user story overzichtelijk te houden.

Hoe schrijf je goede user stories?

Begin in het project met het per stakeholder formuleren van de user stories met een doel. Schrijf de user story in een vorm voor één gebruiker. Inventariseer als customer team bij aanvang van het project zoveel mogelijk relevante user stories. In het begin van het project is het belangrijker om al de user stories te benoemen die nodig zijn in het project dan om user stories in detail uit te werken. Het beschrijven van user stories gebeurt in het begin op een hoog niveau/globale beschrijving. Het opstellen van user stories vindt plaats met als input: Vooral als het een nieuwe dienst/functionaliteit betreft is het belangrijk om de deelnemers te laten beleven wat de dienst inhoudt: visualisatie helpt deelnemers een beeld krijgen van de benodigde/gevraagde functionaliteit. Een bekende manier van visualiseren zijn stroyboards, processchema´s, “a day in the life of...” en prototypes.

Houdt de omvang van een user story beperkt zowel in tekst als in functionaliteit. De relatie tussen een user story, een iteratie en een release is ongeveer als volgt:

De benodigde capaciteit wordt in uren of in punten uitgedrukt. Een goede maat voor de lengte van benodigde capaciteit voor één user story is één dag werk door één medewerker.