Expert in requirements

User stories

User stories zijn in korte tijd zeer populair geworden. Het is dan ook de aanbevolen requirements­techniek in agile omgeving. Tegenwoordig worden de requirements in het grootste deel van de agile of hybride projecten met behulp van user stories opgesteld.

Dit moet je weten als je in een agile omgeving werkt en de user story-techniek ten volle wilt benutten:

Wat zijn user stories?

User stories representeren requirements verteld vanuit het gezichtspunt van de gebruikers. User stories geven de toegevoegde waarde en de behoeften van de gebruikers weer en zijn in de terminologie van de business geformuleerd.

User story template

User stories worden in korte eenvoudige zinnen beschreven bij voorkeur op de volgende manier:

Als een <type gebruiker>
wil ik <iets doen>
zodat ik <er iets aan heb>

Ter illustratie enkele voorbeelden van user stories:

  • Als boekkoper wil ik de beoordelingen van anderen zien, zodat ik de kwaliteit van het boek kan inschatten
  • Als een geregistreerde gebruiker wil ik een nieuw wachtwoord kunnen aanvragen, zodat ik toch toegang kan krijgen als ik mijn wachtwoord ben vergeten
  • Als marketingmanager wil ik de resultaten van oude advertentiecampagnes kunnen zien, zodat ik kan besluiten welke campagnes ik wil herhalen
  • Als student wil ik mijn cijfers online bekijken, zodat ik sneller weet of ik het examen heb gehaald

De 3 onderdelen waaruit een user story bestaat

1. Korte beschrijving

Bovenstaande voorbeelden laten slechts de korte beschrijving van de user stories zien. Het zijn reminders voor de user stories. Het is uitdrukkelijk niet de bedoeling om de user stories ofwel de functionaliteit volledig en tot in detail te beschrijven. Het is namelijk effectiever om de detail­informatie mondeling over te dragen.

2. Mondelinge communicatie

Het tweede en belangrijkste onderdeel van user stories is de mondelinge communicatie, het gesprek tussen het ontwikkelteam en de product owner (gebruiker en/of analist) over de gewenste werking van de user stories. Voordat een ontwikkelaar een user story kan implementeren, heeft hij allerlei detail­informatie nodig. User stories dwingen hem om vragen te gaan stellen aan de product owner. Dit gebeurt tijdens de voorbereiding (in backlog refinement sessies) en tijdens de sprint zelf. De antwoorden worden, voor zover nodig om de correcte werking van de gerealiseerde software vast te stellen, vastgelegd als acceptatie­criteria.

3. Acceptatie­criteria

De acceptatie­criteria vormen het derde onderdeel van user stories. Ook de acceptatie­criteria hoeven niet volledig te zijn, tenminste als het ontwikkelteam en de product owner intensief samenwerken bij het implementeren van de user stories. Requirements detailleren, testen en software ontwikkelen gaan dan hand in hand. De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden.

De voordelen (en beperkingen) van user stories

User stories komen uit de agile beweging voort en ondersteunen derhalve perfect de agile manier van werken. Dat is tegelijkertijd ook de beperking van deze techniek. Als je niet puur agile werkt zijn niet alle voordelen van toepassing en kunnen ze zelfs omslaan in nadelen. In traditionele en sommige hybride omgevingen raad ik user stories dan ook af.

De voordelen van user stories voor agile omgevingen:

  • User stories stimuleren mondelinge communicatie
    Omdat beschrijvingen van user stories geen detail­informatie bevatten, ontkomt het ontwikkelteam niet aan het stellen van vragen aan de product owner.
  • Met user stories werken is eenvoudiger
    Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook want we weten ondertussen dat het onmogelijk is om de requirements volledig en eenduidig te specificeren.
  • User stories kosten minder tijd
    Mondelinge communicatie tussen het ontwikkelteam en de product owner kost minder tijd dan:
    • het specificeren van alle gedetailleerde requirements door een analist
    • het lezen en begrijpen van die specificaties door de ontwikkelaars en testers
    • het doorvoeren van wijzigingen in de specificaties
  • User stories kunnen beter omgaan met voortschrijdend inzicht
    De verschuiving van up front naar just in time requirements, zoals bij user stories het geval is, geeft maximale ruimte voor voortschrijdend inzicht. Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project.
  • User stories hebben de juiste omvang
    In verband met het plannen van sprints/iteraties moeten user stories in maximaal een halve sprint geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, kunnen eenvoudig opgesplitst worden.
  • User stories bevorderen de samenwerking
    Met user stories wordt het mogelijk om de brugfunctie (van de analist) tussen de business en de ICT, te vervangen door een nauwe samenwerking van het ontwikkelteam en de product owner.

Voor analisten die goede user stories met precies genoeg details willen opstellen, heb ik een uitgebreid online programma gemaakt over alle facetten van de user story-techniek. Kijk hier voor informatie over de masterclass Vervolmaken van je user stories.

Succes met de requirements,

Nicole de Swart

PS Vond je dit artikel interessant? Deel het dan op Twitter, LinkedIn, Facebook of Google+ door op onderstaande knoppen te klikken.


Reacties (11)

Onno
Er ontbreekt een stukje: nadelen? Geen evenwichtig verhaal want op deze manier lijkt het alsof use case als requirements techniek geen waarde heeft of plaats heeft t.o.v. user stories. En voor je het weet wordt de ongenuanceerde mening nagesproken zie bijvoorbeeld http://www.raamstijn.nl/eenblogjeom/index.php/requirements/608-storrytelling-en-requirements-user-stories.

Veel van de zogenaamde 'voordelen' kun je niet exclusief aan user stories toeschrijven. Als je user stories 'vergelijkt' met use cases, is het handig om een boek te lezen over use cases bijvoorbeeld Writing Effective Use Case van Alistair Cockburn. Zodat je de nuance kunt zien en dan beschrijven.

Er zitten namelijk wel wat misvattingen in. Bijvoorbeeld, je stelt use cases gelijk met waterval. Nederland heeft de boot gemist met toepassen van de (R)UP. Wij deden RINO. En wij schreven Use Cases of Mass Destruction. Het ontbreekt ons aan kennis van theorie, praktische ervaring (met effectief toepassen) en common sense. Als je niet weet wat je aan het doen bent maakt het niet uit wat je doet: use cases of stories. Wat mij opvalt is onze zelfgenoegzaamheid. Ik heb organisaties geholpen waar de 'ervaren' requirements engineers/functioneel ontwerpers/informatie analisten nog nooit van 'eliciteren' hadden gehoord. Schaamteloos. Met Scrum/Agile lopen we weer een risico wat mij betreft. Er is ook al een naam voor onze projecten: PANDA.

Er is ontzettend veel kennis en ervaring met toepassen van use case, als effectieve requirements techniek. Toch sluiten we ons hier voor af. Ipv kennis nemen van gedachten, overwegingen, ervaringen van mensen zoals Scott Ambler, Alistair Cockborn, Ivar Jacobson praten we elkaar maar een beetje na. Zoals raamstein.nl deze blog.

Ik vind dat we lat hoger moeten leggen en kritischer moeten nadenken over dit soort zaken.
Nicole de Swart
Beste Onno,
Om met je laatste punt te beginnen. Ik ben het helemaal met je eens dat we kennis moeten nemen van de theorieën en ervaringen van de guru's in ons vakgebied. Ik ben overigens erg gecharmeerd van de use case techniek en heb de boeken van Ambler, Cockburn en Jacobson gelezen. Ook het boek Use Case Modeling van Kurt Bittner (werkzaam bij Ivar Jacobson Consulting) is een aanrader.

De blogpost hierboven gaat over requirements in een agile omgeving. Use cases (zoals bedoeld door Jacobson en Cockburn) zijn daarvoor veel minder geschikt dan user stories. Logisch, want ze waren daar ook niet voor bedoeld. In december 2011 heeft Ivar Jacobson overigens use cases 2.0 gelanceerd. Hierin zitten uitbreidingen op de oorspronkelijke use case techniek (bv use case slices) zodat ze breder toepasbaar worden, ook in agile omgevingen.
Pieter Bak
Het juiste niveau van detaillering blijft altijd een discussiepunt in realisatie trajecten. Om een applicatie onderhoudbaar en beheersbaar te houden is een combinatie van beide technieken (user stories en use cases) een oplossing. Begin met user stories om een initiele set van de belangrijkste requirements op te stellen. Schakel daarna over op use case 2.0. Maak een use case model en werk alleen de meest kritische en complexe requirements in detail uit in use case specificaties. De backlog met use stories blijft ook gewoon de basis voor het use case model. Hierdoor is de koppeling tussen story en use case gewaarborgd.
Ik ben zelf erg gecharmeerd van use case 2.0. Deze techniek is goed toepasbaar in agile omgevingen.

Het is maar een werkwijze. Zaak is dat je de goed dingen pakt uit de verschillende methoden en technieken om een optimaal resultaat na te streven (ook naar de toekomst toe).
Info-Analist
US's zijn goed toe te passen op relatief eenvoudige systemen. Maar als de wereld complexer wordt, dan ontkom je er niet aan om meer in de detail te beschrijven. Acceptatiecriteria die 'on the fly' worden besproken en eventueel vastgelegd zijn natuurlijk geen grond om bedrijfskritische systemen te ontwikkelen en te accepteren.

Je schrijft "..werkt het hele ontwikkelteam samen met de product owner om de user stories te detailleren.." In de praktijk komt het er dan op neer dat een business-vertegenwooridger met programmeurs gaat praten, wat een enorme overbruing van een abstractiekloof met zich mee gaat brengen. Informatie-analisten zijn er niet voor niks. Uiteindelijk zal rework en een negatief imago de ICT-ers ten deel vallen.

Nee, de US als business-based beschrijving, een niveau dieper uitgewerkt door Info-analisten die er mean&lean UC's van brouwen en dat bespreken met ontwikkelaars en testers is een werkbare techniek om kwaliteits-systemen te ontwikkelen.
Nicole de Swart
Dank voor je reactie. Dit soort commentaar op de agile werkwijze hoor ik vaker. User Stories en de beperkte documentatie die daarbij hoort werkt niet in een traditionele omgeving. Alleen als je je software-ontwikkeling op een fundamenteel andere manier inricht haal je de voordelen waar agile om bekend staat (één van die voordelen is overigens software van hogere kwaliteit).

Informatie-analisten zijn er inderdaad niet voor niets, maar in agile staan ze niet langer tussen de business en de ontwikkelaars. Als onderdeel van het ontwikkelteam 'faciliteren' ze het rechtstreekse contact tussen de PO en ontwikkelaars. In een traditionele omgeving zou dat niet werken, in een agile omgeving juist wel. Om een paar dingen te noemen: De business en de informatie-analist hoeven niet langer ruim van tevoren alle requirements te achterhalen en SMART te maken (sowieso onmogelijke opgave). In plaats daarvan werken ze requirements just in time uit en stellen de ontwikkelaars vragen ter verduidelijking. Een deel van het requirementswerk verschuift naar geven van feedback op (deels) gerealiseerde software. Streven naar volledigheid is onverstandig en wijzigen/toevoegen aan de requirements worden juist gestimuleerd in agile.

Meer hierover heb ik beschreven in het e-boek 'De Agile Analist'. GRATIS te downloaden op http://www.reaco.nl/agile-analist/
Judith van Eijk
Hoe verhoudt zich bovenstaande met near- en off-shore ontwikkeling? Mijn ervaringen voor ontwikkeling zonder UC's zijn daarmee niet erg positief: agile vraagt m.i. om een fysiek op 1 plaats geconcentreerd ontwikkelteam incl. een ter zake kundige en beslissingsbevoegde business vertegenwoordiger. De realiteit is anders..
Nicole de Swart
Judith, voor een agile werkwijze en user stories is inderdaad een ter zake kundige en beslissingsbevoegde business vertegenwoordiger (product owner) onmisbaar.

Een fysiek op 1 plaats geconcentreerd ontwikkelteam heeft wel de voorkeur maar is zeker niet noodzakelijk. Er zijn genoeg voorbeelden van succesvolle 'distributed agile teams'. Kijk bijvoorbeeld op http://jaoo.dk/file%3Fpath=/jaoo-aarhus-2008/slides/JeffSutherland_FullyDistributedScrum.pdf
en het vaak geciteerde artikel van Jeff Sutherland http://jeffsutherland.com/SutherlandDistributedScrumHICCS2007.pdf
Johan
Ik ben persoonlijk een groot voorstander van User Stories. Maar de beschrijving hier van de Product Owner (PO) staat me een beetje tegen. De PO overlegt met de business/gebruikers over de vereisten op user story niveau en zorgt voor de juiste prioritisering voor het team. De details moet het team echter zelf met de business/gebruikers vaststellen. Als je de juiste ontwikkelaars hebt kunnen die prima met de business overleggen en daar zou geen 'proxy' (=PO) tussen moeten zitten. Ik ben het daarmee volledig oneens met de opmerkingen van de Info-Analist.

Daarnaast zijn virtuele teams mogelijk maar allesbehalve optimaal. Als je gaat off shoren naar bv India, dan kun je deze manier van werken wel vergeten, omdat mensen van India simpelweg niet gaan vragen naar de details. Ze doen of helemaal niets, of ze bouwen iets zonder vragen te stellen.
Rik Manhaeve
Naar mijn mening zijn de doelstellingen die bij user stories dikwijls worden naar voor geschoven geen doelstellingen van de gebruiker maar eerder subdoelstellingen. Dit leidt tot functionaliteiten waarbij het overkoepelende doel verloren gaat en de manier waarop aan de ontwikkelaar wordt overgelaten. U kunt dit laatste voor een groot stuk opvangen via prototyping maar het is niet nuttig om dit voor alle 'functionaliteiten' te doen. Een verzameling patterns die vastleggen hoe u een bepaald probleem oplost kunnen dit werk sterk vereenvoudigen en versnellen.

Ik neem als voorbeeld de eerste 'user story'.
Als boekkoper wil ik de klantbeoordelingen van een boek lezen zodat ik beter kan beslissen of ik het boek wil kopen.
De omschrijving met 'beter' geeft aan dat de beslissing voor het kopen van een boek meer is dan deze user story laat uitschijnen (prijs, leverbaarheid, verzendingskosten ...).. U kunt daar allemaal user stories van maken maar die zullen waarschijnlijk ook dezelfde doelstelling hebben en dan wordt het snel onoverzichtelijk.
Hoeveel ontwikkelaars (of wie het ook doet) zullen 'beter' erbij vermelden. Laat dit weg en de doelstelling wordt fout.
Ik zou dit eerder omschrijven als:
Als boekkoper wil ik de beoordelingen van anderen zien zodat ik de kwaliteit van het boek kan beoordelen (onderdeel van het doel van kopen).
Een overkoepelende user story (eerder een epic) zou kunnen zijn:
Ale vijetijdsbesteder wil ik een boek kopen zodat ik die vrije tijd op een voor mij aangename manier kan doorbrengen.

Ik verwijs hierbij naar de 'Human Action Cycle' van Donald Norman.
Nicole de Swart
Hallo Rik, Ik vind je user story-zin 'Als boekkoper wil ik de beoordelingen van anderen zien zodat ik de kwaliteit van het boek kan beoordelen' een goede verbetering. Dank daarvoor.
CHC
Goed artikel, geef een kort en duidelijk overzicht van user stories (met leuek voorbeelden). Ik vind US een zeer geschikte tool is voor het vastleggen van requirements in een Agile/Scrum omgeving. Hier moet echter wel een mits worden geplaatst, namelijk dat Agile/Scrum goed is geïmplementeerd in de organisatie. Zolang dat niet is gebeurd, kun je elke techniek wel vergeten, dan werkt er namelijk niets. Verder is het zo dat US je geen beperkingen oplegt qua mate van detaillering - je kunt het simpel houden, of een complete boekwerk van maken.

Het bovenstaande geldt ook voor eventuele off-shore ontwikkelteams. Veel bedrijven maken de fout door off-shore teams op te leggen dat ze Agile/Scrum gaan doen, maar vergeten de werkwijze/mentatliteit van Agile/Scrum goed te implementeren.

Geef een reactie

Gratis preview Handboek Requirements

Cover ‘Handboek Requirements’

Lees alvast 5 hoofdstukken uit het compleet vernieuwde boek

Nicole de Swart

Nicole de Swart

Volg Nicole op:

Gratis video met tips voor user stories

Masterclass ‘Vervolmaken van je user stories’

Ontdek hoe je 5 door analisten veel gemaakte fouten omzeilt