In het grootste deel van de agile of hybride projecten worden de requirements met behulp van user stories opgesteld. Het is ook niet voor niets de aanbevolen requirements­techniek voor agile omgeving.

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. Ze zijn in de terminologie van de business geformuleerd.template user stories

Een user story wordt in een korte eenvoudige zin weergegeven. Bij voorkeur op de volgende manier:

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

Ter illustratie enkele voorbeelden:

  • 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

Een user story bestaat uit 3 onderdelen

Als men het over user stories heeft, wordt vaak alleen de beschrijving van een user story bedoeld. Lang niet iedereen weet dat een user story uit drie onderdelen bestaan én dat de beschrijving niet de belangrijkste is.

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 een user story, ofwel de gewenste functionaliteit, volledig en tot in detail te beschrijven. Het is bedoeld als uitnodiging om met elkaar in gesprek te gaan (zie volgende onderdeel).

2. Mondelinge communicatie

Het tweede en belangrijkste onderdeel van een user story is de mondelinge communicatie. Het gesprek dus tussen de product owner (gebruiker en/of analist) en de teamleden over de gewenste werking van de software.

Voordat een ontwikkelaar een user story kan implementeren, heeft hij allerlei detail­ informatie nodig. De korte beschrijving dwingt 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. (Hier vind je een uitgewerkt voorbeeld.) Tenminste als de product owner en de teamleden 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. Ze 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. Het kan zelfs omslaan in nadelen. In traditionele en sommige hybride omgevingen raad ik user stories dan ook af.

De voordelen van user stories in agile omgevingen:

> Ze stimuleren mondelinge communicatie

Omdat beschrijvingen van user stories geen gedetailleerde ­informatie bevatten, ontkomen de teamleden niet aan het stellen van vragen aan de product owner.

> Het is eenvoudiger dan traditionele requirements

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.

> Het kost minder tijd

Mondelinge communicatie tussen de teamleden 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

> Je kunt beter omgaan met voortschrijdend inzicht

Doordat je een user story pas kort voor de sprint uitwerkt, creëer je maximale ruimte voor voortschrijdend inzicht. Tot aan de start van de sprint waarin de story geïmplementeerd wordt, heeft voortschrijdend inzicht nauwelijks een negatief effect op het project.

> Ze hebben de juiste omvang

In verband met het plannen van sprints moeten user stories in maximaal een halve sprint geïmplementeerd kunnen worden. Grotere user stories, epics genoemd, kunnen eenvoudig opgesplitst worden.

> Ze bevorderen de samenwerking

Met user stories wordt het mogelijk om de brugfunctie (van de analist) tussen de business en IT, te vervangen door een nauwe samenwerking van de product owner met de teamleden.

Meer lezen?

User stories kun je pas succesvol toepassen als je het complete plaatje kent. Zoals je hierboven hebt gelezen komt er meer bij kijken dan alleen de zin ‘Als <gebruiker> wil ik, …’.

Stel jezelf bijvoorbeeld de volgende vragen:

  • Hoe krijgen de ontwikkelaars op tijd de benodigde informatie?
  • Hoever moeten we de user stories uitwerken?
  • Hoe weet ik of de user stories de gebruikersbehoeften correct weergeven?
  • Hoe houd ik de business stakeholders het hele project betrokken?
  • Hoe houd ik de user stories actueel?
  • Hoe houd ik overzicht over alle user stories die er zijn?

Deze vragen vormen de sleutel om meer resultaat te boeken met user stories. In mijn e-book ‘Haal meer uit user stories’ lees je wat daar voor nodig is.

Nicole de Swart

Misschien vind je dit ook interessant

11 reacties

  • 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 .

    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 agile team ‘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.

  • 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..

  • Joahn

    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