Artikel

User stories sprint ready maken

Veel agile projecten maken voor het achterhalen van requirements gebruik van user stories. Een user story is iets dat de gebruiker wil en wordt bij voorkeur beschreven als: Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>. Deze user stories worden opgenomen in de product backlog, een geprioriteerde lijst van alles dat het team nog moet realiseren. Een user story is in eerste instantie groot en veelomvattend. Naar mate de prioriteit van de user story stijgt en daarmee het moment van implementatie dichterbij komt, splitsen agile teams de user story op in steeds kleinere stories. De product backlog bevat daarom zowel grote als kleine user stories.

Dit is weergegeven in figuur 1. Het geleidelijk steeds verder opsplitsen van een user story gaat door totdat de story klein genoeg is om in enkele dagen te implementeren. Zo'n kleine story wordt een sprint ready user story genoemd omdat hij klaar is om in een sprint(planning) op te nemen. 

 



figuur 1, product backlog

In de praktijk blijken veel agile teams (inclusief product owner) bij het sprint ready maken van user stories moeite te hebben met het business value-criterium. Iedere user story moet immers op zichzelf business value leveren. Op deze manier kunnen de user stories die op dat moment de meeste business value leveren, geselecteerd worden voor de volgende sprint. Aan het einde van de sprint levert het agile team productierijpe software op. Alleen dan is het mogelijk om te voldoen aan het belangrijkste agile principe: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" [Agile manifesto]. Door iteratief en incrementeel te ontwikkelen breiden agile teams software, met in eerste instantie basale functionaliteit, steeds verder uit. Dit is te vergelijken met het steeds groter groeien van een boom.

figuur 2.1, Net geplante bomen

figuur 2.2, Jonge bomen 

figuur 2.3, Volwassen bomen

 

Sprint ready in 3 stappen

Dit artikel laat zien hoe je user stories, met behoud van business value, kunt opsplitsen in stories die klein genoeg zijn om in een sprint te implementeren. De beschreven aanpak bestaat uit drie stappen voor het sprint ready maken van user stories. In figuur 3 is de eerste stap op de horizontale as en de tweede stap op de verticale as gepositioneerd.



figuur 3, Sprint Ready

Het gaat om de volgende stappen:

  1. Minimaliseren van de acties
  2. Minimaliseren van de features
  3. Samenstellen van sprint ready user stories

De aanpak is geïnspireerd op story mapping [Jeff Patton] en op story splitting patterns [o.a. Richard Lawrence]. Deze patterns (patronen) laten zien welke mogelijkheden er zijn om user stories op te delen in kleinere user stories.

Stap 1. Minimaliseren van de acties

Een (grote) user story bevat verschillende impliciete en expliciete acties van het systeem. Sommige van deze acties leveren veel en andere minder of zelfs helemaal geen business value. In deze stap worden uitsluitend de acties die cruciaal zijn voor de gebruikers en/of andere stakeholders geselecteerd. Het absolute minimum dat nodig is om (enige) business value te leveren. Dit zijn zelden meer dan twee of drie acties. Ter illustratie het volgende voorbeeld van een user story voor een hotelreserveringssite.

Als hotelgast wil ik een hotelkamer reserveren zodat ik zeker weet dat ik het hotel kan overnachten.

Deze user story is veel te groot om in een sprint te implementeren. Om hem sprint ready te maken is opsplitsing noodzakelijk. Hiertoe concentreren we ons in deze eerste stap op het werkwoord 'reserveren'.

Het reserveren van een hotelkamer bestaat onder andere uit de acties: opgeven zoekcriteria, tonen gevonden hotels, bekijken hotelinformatie, controleren beschikbaarheid, selecteren hotelkamer, invoeren persoons- en kredietkaartgegevens. Het absolute minimum om de business value 'zeker weten dat ik in het hotel kan overnachten' te leveren is: opgeven hotelnaam en overnachtingsdatum + ontvangst van een reserveringsbevestiging.

De overige acties kunnen zeer gewenst zijn of zelfs noodzakelijk voor de in gebruik name van het systeem, maar genereren slechts aanvullende business value. Ze komen daarom in afzonderlijke user stories te staan.

Bijvoorbeeld het zoeken naar en selecteren van een hotel(kamer) wordt een afzonderlijke user story, net als het opgeven van persoons- en kredietkaartgegevens om de reservering definitief te maken. Het hotel zou immers een kamer kunnen garanderen aan iedereen die een uitgeprinte reserveringsbevestiging laat zien. Niet handig, maar het kan. De minimale variant van de user story luidt daarom:

Als hotelgast wil ik een reserveringsbevestiging ontvangen nadat ik een hotelnaam en overnachtingsdatum heb opgegeven, zodat ik zeker weet dat ik in het hotel kan overnachten.

Patterns die betrekking hebben op het minimaliseren van de acties:

  • Workflow stappen

Dit pattern geeft aan dat een user story vaak op te splitsen is in zijn onderliggende acties. In het voorbeeld van de hotelreserveringssite is dit pattern gebruikt.

  • CRUD (acroniem voor de operaties create, read, update en delete)

Dit pattern geeft aan dat het mogelijk is om woorden als managen, beheren en onderhouden verder op te splitsen. Vaak is 'wijzigen' te vervangen door 'verwijderen en vervolgens opvoeren'.

  • Rollen

Dit pattern geeft aan dat het soms mogelijk is om een user story te vereenvoudigen door te focussen op een bepaalde stakeholder of rol. Als voorbeeld de user story:

Als gebruiker wil ik hulp als er een systeemfout optreedt zodat ik daarna verder kan werken.

Afzonderlijke focus op de gebruiker en op de helpdesk resulteert in de user stories:

Als gebruiker wil ik bij het optreden van een systeemfout een begrijpelijke foutmelding zodat ik kan beoordelen of ik het zelf kan verhelpen of de helpdesk moet bellen.

Als helpdesk wil ik bij het optreden van een systeemfout een unieke foutcode hebben zodat ik het probleem eenduidig kan vaststellen.

 

Stap 2. Minimaliseren van de features

In deze stap worden de features teruggebracht tot het absolute minimum. Net genoeg om de user story uit te voeren en dus de beoogde business value te leveren. De wijze waarop een systeem de functionaliteit biedt kan namelijk variëren van heel eenvoudig en basic tot bijzonder luxe. Dit geldt bijvoorbeeld voor de lay-out van de schermen, het aantal gegevens en het gedrag van het systeem. Het is gebruikelijk om de wijze waarop het systeem de functionaliteit moet leveren, op de nemen als acceptatiecriteria bij de user story.  

De in stap 1 gevonden minimale user story kan op verschillende manier geïmplementeerd worden. Vaak gaan we impliciet uit van een gebruikersvriendelijke werking. In deze stap brengen we dat terug tot het absoluut minimum.

We beperken de minimale user story van de hotelreserveringssite bijvoorbeeld tot het reserveren van slechts één hotelkamer voor één nacht. Als meer kamers en/of nachten gewenst zijn, moet de hotelgast evenzoveel reserveringen plaatsen.

Het verstrekken van een reserveringsbevestiging beperken we in de minimale variant tot het tonen van de bevestigingsgegevens op het scherm zodat de hotelgast een schermprintje kan maken. Het tonen van een printvriendelijke versie of het sturen van een e-mail is gebruikersvriendelijker maar komt in een andere user story te staan. Die andere user story luidt dan:

Als hotelgast wil ik als reserveringsbevestiging een e-mail ontvangen zodat ik eenvoudig kan aantonen dat ik een kamer gereserveerd heb.

Patterns die betrekking hebben op het minimaliseren van de features:

  • Simpel/complex

Dit pattern geeft aan dat user stories vaak op te splitsen zijn in een variant met zeer eenvoudige functionaliteit en aanvullingen en uitbreidingen daarop. Het voorbeeld van de reserveringsbevestiging valt hieronder.

  • Gegevens

Dit pattern geeft aan dat met minder gegevens nog steeds business value geleverd kan worden. De minimaal benodigde gegevens komen dan in een afzonderlijke user story en de overige gegevens in één of meer andere stories. Dit is bijvoorbeeld het geval bij de beperking dat er slechts één hotelkamer voor één nacht gereserveerd kan worden. Het aangeven van het aantal hotelkamers en het aantal nachten komen in één of twee afzonderlijke user stories.

  • User interface

Dit pattern zegt dat de user interface meestal aanknopingspunten biedt om de user story verder op te splitsen. Bijvoorbeeld (complexe) invoercontroles en handige invoermethodes zoals het selecteren van een datum op een kalender worden dan in een andere user story ondergebracht.

  • Business rules

Dit pattern geeft aan dat user stories soms op te splitsen zijn door het voldoen aan een business rule in een afzonderlijke user story op te nemen. Een voorbeeld hiervan is het in eerste instantie weergeven van de prijzen in  uitsluitend euro's. Dat de klant zelf een munteenheid kan kiezen (business rule) plaatsen we dan in een andere user story.

  • Niet-functionele requirements

Dit pattern geeft aan dat het mogelijk is om niet-functionele requirements in afzonderlijke user stories op te nemen. Dit geldt onder andere voor eisen ten aanzien van de snelheid, de schaalbaarheid en de nauwkeurigheid.

 

Stap 3. Samenstellen sprint ready user stories

De voorgaande stappen hebben geresulteerd in de kleinst mogelijke user story die nog net business value levert en in aanvullende acties en features die daar extra business value aan toevoegen. In deze stap worden daaruit sprint ready user stories samengesteld rekeninghoudend met de omvang en de prioriteit van de user stories. Aangezien de gewenste omvang van een sprint ready story voor ieder agile team anders is, bekijkt het team eerst of ze de kleinst mogelijke user story in enkele dagen kan implementeren. Voor zover daar ruimte voor is voegt het team er aanvullende acties en/of features aan toe. Uiteraard in volgorde van prioriteit. Dit leidt tot de eerste en hoogst geprioriteerde sprint ready user story. De andere user stories ontstaan door van de aanvullende acties en features afzonderlijke user stories te maken.

Voor de actie 'opgeven zoekcriteria' maken we bijvoorbeeld de user story:

Als hotelgast wil ik met behulp van zoekcriteria een hotelkamer selecteren zodat ik een kamer kan reserveren die aan mijn wensen voldoet.

Door het aantal zoekcriteria te beperken is te voorkomen dat deze user story te groot wordt.

Alleen de acties en features die onmisbaar zijn voor de eerstvolgende release worden in een user story opgenomen. De andere acties en features komen, als ze voor de klant belangrijk genoeg zijn, vanzelf op een later moment weer naar voren.

Als het agile team meer dan een week nodig heeft om de in stap 1 en 2 gevonden kleinst mogelijke user story te implementeren, is verder opsplitsen nodig. Dit heeft als consequentie dat de user story te klein wordt om op zichzelf business value te leveren. Er zijn dan meerdere user stories nodig voor het leven van business value. Aangezien we dat juist proberen te vermijden, is verder opsplitsen het laatste redmiddel. De ervaring leert dat verder opsplitsen zelden nodig is als de eerste twee stappen adequaat doorlopen zijn.

Samenvatting

Het continu leveren van business value heeft voor agile teams de hoogste prioriteit. Hiertoe leveren ze ieder sprint werkende en voor de business waardevolle software op. Agile teams implementeren iedere sprint een aantal user stories. Die user stories moeten klein genoeg zijn en op zichzelf business value toevoegen aan de reeds ontwikkelde software. Bij het opsplitsen van user stories in kleinere sprint ready user stories blijkt dat het in de praktijk vaak lastig is om te voldoen aan het business value-criterium. De gepresenteerde aanpak laat zien hoe in drie stappen sprint ready user stories zijn te definiëren. Door de user story zowel langs de actie-as als langs de feature-as te minimaliseren, is de kleinst mogelijke user story die op zichzelf business value levert, te vinden.

Categorie:   
Auteur(s)
afbeelding van reaco
Nicole de Swart
Reaco Academy - Requirements expert

Nicole de Swart is auteur van Handboek Requirements en oprichtster van het Requirements Kenniscentrum. Via de Reaco Academy helpt Nicole requirementsanalisten de overstap naar agile te maken. Daarnaast geeft ze les aan studenten Business Information & Management op de Hogeschool van Amsterdam.

 
Reacties
Mark Paauwe op woensdag 2 mei 2012 9:34

Verfrissend artikel!

Nicole, heb je misschien ook ergens voorbeelden van uitgewerkte user stories?

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.