User Stories

In de wereld van Agile is het Scrum Framework verreweg het meest populaire framework. Het biedt een iteratieve en incrementele aanpak om een product te leveren welk de meeste waarde bevat voor de klant. Scrum is een uitgebreid Framework met tal van facetten, vandaag focussen we ons op één van de begrippen die bekend en berucht is: User Stories.

Bekend omdat ze vaak gebruikt worden en een best practice vormen voor diegenen die het kennen. Berucht omdat niet iedereen het begrijpt dan wel in staat is om de juiste waarde uit dit concept te halen. Binnen Scrum spelen User Stories, Epics en tasks een belangrijke rollen bij het definiëren van vereisten, plannen van ontwikkeling en beheren van voortgang. In dit artikel geven we antwoord op de vraag waarom User Stories zo belangrijk zijn en maken wij de vergelijking tussen Epics, User Stories en Tasks zodat we alle drie de niveaus goed begrijpen.

User Stories: Beschrijving van Klantwaarde

User stories zijn korte, eenvoudige beschrijvingen van behoeften die vanuit het perspectief van de eindgebruiker worden geformuleerd. Gezamenlijk zorgen de User Stories voor de bouwstenen van het eindproduct. Niet alleen dat, User Stories helpen begrijpen en prioriteren welk van deze bouwstenen de meeste waarde bevat voor de klant zodat je daarmee als eerst aan de slag kunt gaan. De format voor een User Story is daarom ook zo ontworpen dat het je afdwingt om niet alleen na te denken over wat de klant wil, maar ook waarom de klant dat wil. Ofwel, wat is de waarde die de klant terugziet op het moment dat deze User Story opgeleverd is.

Een typische user story heeft de volgende structuur: “Als [gebruiker], wil ik [actie], zodat [reden].”

De kenmerken van user stories zijn:

Klantgericht: User Stories zijn gefocust op de eisen en wensen van de eindgebruiker. Daarom beginnen ze met “Als [gebruiker], wil ik [actie], zodat [reden].” Het kan zijn dat er één klant is of één gebruikersgroep die uiteindelijk gebruik gaat maken van het product. Echter is het veel voorkomend dat er verschillende type gebruikers en gebruikersgroepen zijn. Ieder met een eigen wens voor het product en daaraan gekoppelde Userstories. Zo kunnen verschillende leeftijdsgroepen hele andere wensen hebben als het gaat om beleving tijdens een diner.

Beknopt en Begrijpelijk: User Stories zijn kort en gemakkelijk te begrijpen voor alle teamleden en stakeholders. Ze vermijden technische details en jargon. Een User Story kan wel altijd aangevuld worden met extra documentatie, specificatie van requirements of andere benodigdheden om de realisatie ervan te vergemakkelijken. Dat gezegd hebbende is het doel nog steeds om te begrijpen wat de klantwaarde is.

Onafhankelijk: Elke user story kan op zichzelf staand worden ontwikkeld en geïmplementeerd. Hierdoor kunnen de Developers of projectleden zich op één functie tegelijk richten. Deze focus verhoogt de kwaliteit, verkort de levertijd en stelt het team in staat om samen met de klant kort cyclische successen te vieren.

Waardevol: Elke user story moet waarde toevoegen aan het eindproduct. Dit waarde-aspect helpt bij het prioriteren van het werk dat gedaan moet worden. Het doel is dus niet alleen inzicht krijgen in wat er gedaan moet worden om het product te realiseren of wat de waarde is van ieder individueel User Story, maar het is ook nog een middel om te vergelijken welke User Stories de meeste waarde toevoegen en daarmee als eerste opgepakt zouden moeten worden.

Een paar voorbeelden van User Stories:

Voorbeeld: Als een frequente koper, wil ik punten kunnen verdienen voor elke aankoop die ik doe, zodat ik kortingen kan krijgen op toekomstige aankopen.

Voorbeeld: Als frequent flyer wil ik sneller door de procedures van het vliegveld zodat ik mijn wachttijd minimaliseer.

Voorbeeld: Als hotelgast wil ik online kunnen inchecken en een digitale kamersleutel ontvangen, zodat ik wachtrijen kan vermijden en een soepele aankomstervaring kan hebben.

Voorbeeld: Als restaurantbezoeker wil ik online een reservering kunnen maken, zodat ik op het gewenste tijdstip een tafel kan reserveren zonder gedoe.

Wat opvalt aan User Stories is dus dat het een uitdaging of klantwens omschrijft en wat de toegevoegde waarde is voor die gebruiker. Wat het niet doet is ook vermelden hoe deze waarde gerealiseerd dient te worden. De User Story omschrijft dus de ‘wat’ en niet de ‘hoe’. Reden hiervoor is dat we in een complexe omgeving werken. Hierdoor zijn we immers gaan kijken naar het Agile Framework en hebben we het Scrum Framework geselecteerd. Nog een gevolg van de complexiteit waar we zitten is dat antwoorden op problemen of wensen vaak niet eenduidig zijn. Vaak moeten verschillende ideeën en alternatieven afgewogen worden om de beste keuze te kunnen maken tussen klantprobleem of klantwens en producteisen. De Product Owner is samen met de klant verantwoordelijk voor het zo goed mogelijk definiëren van de klantwens doormiddel van een User Story (ofwel de ‘wat’). Vervolgens kijken de Developers op projectleden ‘hoe’ ze deze vraagstuk gaan vertalen naar een functionaliteit van het product of uitkomst van een project. Op deze manier kom je tot gedragen oplossing gebaseerd op klantwaarde en gerealiseerd vanuit expertise!

Epics: Een Letterlijk Container Begrip

Epics vertegenwoordigen grotere eenheden van werk dan user stories. Ze omvatten complexere functionaliteiten die in kleinere stukken kunnen worden opgedeeld: ofwel User Stories. Een Epic kan worden gezien als een container voor gerelateerde user stories die samen een grotere functie of feature vervullen. Zo kun je bijvoorbeeld de klantwensen rondom alle informatie die de bestuurder wil tijdens het rijden samenbrengen tot de container: dashboard. Deze container bestaat echter wel uit allemaal individuele User Stories met betrekking tot de specifieke elementen die de gebruiker wil of juist niet wil.

Kenmerken van Epics zijn:

Complexiteit: Epics omvatten vaak meerdere aspecten en kunnen meerdere Sprints nodig hebben om volledig te worden afgerond. Hierom kunnen Epics zelf dus ook niet opgeleverd, dit duurt te lang en begint op waterval te lijken. Ze worden opgebroken in User Stories die vervolgens wél in één Sprint kunnen worden opgeleverd.

Opdeling: Epics kunnen worden opgedeeld in kleinere User Stories. Ook User Stories zijn op te breken in Tasks of zelfs Sub-Tasks, maar daar hebben we het zo over. Voor dat laatste geldt overigens dat deze niet verder opgebroken kan of hoeft te worden.

Lange termijn: Epics vertegenwoordigen vaak functionaliteit die zich uitstrekt over meerdere Sprints of zelfs de gehele ontwikkelperiode. Zo kan een Epic zijn dat je bepaalde onderdelen van je product, gebouw of applicatie modificeert voor specifieke gebruikersgroepen. User Stories in deze Epic kun je vanaf het begin van het project proberen te formuleren, maar dat gaat waarschijnlijk niet lukken. Na het opleveren van een aantal incrementen, daarentegen, heb je de gelegenheid om de ontvangen feedback te verwerken in een nieuwe iteratie.

Taken (Tasks): Specifieke Acties om User Stories te Voltooien

Taken zijn specifieke acties of activiteiten die moeten worden uitgevoerd om een user story te realiseren. Ze vertegenwoordigen de kleinste eenheden van werk in Scrum en helpen bij het structureren en inschatten van het werk dat gedaan moet worden. Taken worden geschreven en uitgevoerd door de Developers of projectleden. Samen vormen de taken het plan van ‘hoe’ de User Story gerealiseerd gaat worden.

Kenmerken van taken zijn:

Concreet: Taken zijn erg specifiek omschreven. Er mag geen twijfel bestaan over wat hetgeen is dat je gaat doen en is daarmee in principe ook overdraagbaar naar andere projectleden.

Toegewezen: Elke taak wordt meestal toegewezen aan een specifiek teamlid die namens het team de taak op zich neemt.

Meetbaar: Het is mogelijk om de voortgang van taken te meten, wat helpt bij het beoordelen van de Sprintvoortgang. De verantwoordelijkheid hiervan ligt bij het team. Een taak is simpel te beoordelen, namelijk als ‘af’ of ‘niet af’.

Vergelijking tussen User Stories, Epics en Taken

We hebben het gered. Alle drie de abstracties van het Scrum Framework hebben we in bovenstaande paragraven behandeld. Om er zeker van te zijn dat alle kwartjes zijn gevallen maken we nog even de vergelijking tussen Epics, User Stories en Tasks vanuit.

Als we naar de drie abstracties kijken vanuit de complexiteit dan zien we dat User Stories relatief klein en beheersbaar zijn in vergelijking met Epics. Epics zijn groter er complexere containers waarin meerdere User Stories zitten en hebben doorgaans een langere doorlooptijd dan één sprint. Tasks daarentegen zijn de kleinste en meest gedetailleerde eenheden van werk en vormen samen de benodigdheden om een User Story af te maken. Hierop voortbordurend zien we dat Tasks juist het meeste detail bevatten en specifieke acties zijn. User Stories zijn minder gedetailleerd en vooral bedoeld om waarde te definiëren vanuit het oogpunt van de gebruiker. Tot slot zijn Epics meer een overkoepelende beschrijving zijn van een grotere functionaliteit. Tot slot zien we op planningsniveau dat User Stories opgenomen worden in de product backlog om vervolgens in elke Sprint geselecteerd te worden voor de realisatie van het deelproduct (of Increment zoals dat in Scrum heet). Epics kunnen meerdere Sprints bestrijken en worden opgedeeld in User Stories voor de planning. Tot slot worden Tasks geïdentificeerd en toegewezen tijdens de Sprint Planning en gedurende de Sprint.

Extraatje: User Story Points

User Story points worden vaak gebruikt in Scrum om de inspanning en complexiteit van User Stories in te helpen schatten. Ze zijn relatieve eenheden van maatstaven die het team helpen om de onderlinge verhouding van werk te begrijpen zonder zich vast te leggen op specifieke uren. Zo kunnen onbekendheden en onenigheden bespreekbaar worden gemaakt zodat het team dezelfde beeld heeft van de User Story.

Bij het schatten van story points houdt het team rekening met factoren zoals complexiteit, technische uitdagingen en afhankelijkheden. Het gebruik van de Planning Poker-techniek helpt bij de beeldvorming van de User Story en het verkrijgen van consensus binnen het team over het op te leveren deelproduct. Door story points te gebruiken, kan het team de capaciteit beoordelen, realistische doelen stellen voor elke Sprint en de snelheid van het werk in de loop van de tijd beter inschatten. Zodoende kunnen ze op een realistische wijze inschatten wanneer deelproducten af zullen zijn, maar ook het product in zijn geheel een bepaalde volwassenheid bereikt.

Conclusie

Met een goed begrip van User Stories, Epics, Taken en User Story Points kun je effectiever werken binnen het Scrum Framework. Deze concepten helpen bij het vastleggen van klantvereisten, organiseren van het werk en beheren van de voortgang. Door ze op de juiste manier te integreren, kun je waardevolle software ontwikkelen. Let wel, hoewel deze begrippen zelf een logische opbouw hebben en open deuren lijken, is de succes van je team afhankelijk van de discipline waarmee je de begrippen weet toe te passen binnen je Scrum Team. Het is geen doel op zich, maar ook absoluut geen overbodige documentatie.

Mocht je nog moeite hebben met deze begrippen of de praktische toepasbaarheid ervan, wij kijken graag met je mee!