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:
- 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)
- Discussie over de user story om de details boven tafel te krijgen
- Details worden vastgelegd op de user story kaart
- 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:
- I – Independent: beschrijft een deel niet-overlappende functionaliteit die onafhankelijk van elkaar geïmplementeerd kunnen worden
- N - Negotiable (and Negotiated): zijn onderhandelbaar, klant (product owner) en ontwikkelteam bespreken de functionaliteit en bespreken de mogelijkheden om een user story iets bij te stellen waardoor deze gemakkelijker (=goedkoper/sneller/stabieler) te realiseren is
- V – Valuable: waardevol voor tenminste één van de stakeholders, zoals gebruikers en klanten.
- E – Estimable: team kan de complexiteit en benodigde capaciteit bepalen om de user story te realiseren
- S – Small: realisatie van user story is voldoende klein ten opzicht van doel. Bij implementatie dient implementatie van user story korter te duren dan een iteratie. Bij user stories die later gerealiseerd worden, kan een user story langer duren (idee is dat deze user stories later nog verfijnd en opgedeeld worden).
Een bijzondere user story is `onderzoek´ of 'spike': de user story beschrijft wat het onderzoek inhoudt.
- T – Testable: klant, ontwikkelaars en testers weten precies wat user story inhoud en waarop deze beoordeeld wordt met het testen.
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:
- klant zal online een hypotheekaanvraag kunnen registreren.
En niet:
- een klant kan op de site een hypotheekaanvraag invoeren
- de hypotheekaanvraag van de klant wordt in een database vastgelegd.
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:
- functioneel beheerder zal aanbiedingen op de site kunnen plaatsen, wijzigen, verwijderen
- functioneel beheerder kan een termijn voor aanbieding instellen waarop ze zichtbaar zijn
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:
- Niet-functionele eisen (optioneel)
- Aanvullende details/scenario's voor testen (vereist)
- Beperkingen/voorwaarden (optioneel)
- Story points of de capaciteit die nodig is user story te ontwikkelen (vereist)
- Prioriteit (vereist)
- 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:
- interviews
- vragenlijsten
- observaties op de werkvloer
- brainstorm sessies (bij voorkeur met visualisatie)
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:
- x user stories = 1 iteration (2-4 weken)
- x iteraties = 1 release (3-6 maanden)
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.