User Story’s zijn een bekende en veel gebruikte term in Agile werken. Vooral in Scrum kom je de User Story nog wel eens tegen. Wij krijgen in onze trainingen veel vragen over User Stories, en dat is een goede reden om, nu we het toch over Story’s hebben, de feiten en de fabels eens van elkaar te scheiden. In dit artikel zullen we dieper ingaan op wat een User Story is.
Een veelgebruikte definitie van User Story is: Het is een korte, eenvoudige beschrijving van een functie of functionaliteit vanuit het perspectief van de eindgebruiker. Het beschrijft wie de gebruiker is, wat hij wil bereiken en waarom.
User Stories worden vaak gebruikt om de vereisten voor een project te communiceren en te prioriteren. Het is geen verplichting Agile softwareontwikkeling. Ze helpen teams om zich te concentreren op de behoeften van de eindgebruiker en stellen hen in staat om waardevolle functionaliteit te leveren in kleine, behapbare stukjes.
User Story’s helpen, zoals gezegd, bij het definiëren van de gewenste functionaliteit vanuit het perspectief van de gebruiker. In een user story staat niet alleen wie de gebruiker is, en welke functionaliteit deze nodig heeft, maar ook waarom dat is. Zo kan een Scrum team zich beter concentreren op het leveren van waarde voor die precieze gebruiker, en door die te benoemen wordt het ophalen van goede feedback ook wat eenvoudiger voor de Developers.
Er is nog een belangrijke andere reden: De Product Owner is er in Scrum formeel verantwoordelijk voor om wat de stakeholder wil, en waarom hij dat wil, op te halen en geprioriteerd op de Product Backlog te plaatsen. Hij is niet verantwoordelijk voor HOE het gefabriceerd of uitgevoerd wordt—dat zijn de Developers. Door een User Story te gebruiken, wordt het gemakkelijker voor de PO om zich te houden aan die rolverdeling en uit de productomschrijvingen te blijven—hij schetst zo eigenlijk een beeld van een product, geeft richting zonder te vertellen wat het team moet doen. Micro-management van de Developers door de PO wordt zo voorkomen.
Een User Story volgt meestal een eenvoudig format, bekend als het “Als… dan… omdat…” format. Hier is hoe je een User Story kunt schrijven:
Ontvang een handige User Story Template direct in je inbox, ideaal voor jouw Scrum Planning.
Je naam
Je telefoonnummer
Je e-mail adres
We kunnen contact met je opnemen via e-mail of telefoon om de template toe te lichten. Door dit formulier te verzenden, geef je ons toestemming voor contact. Je kunt deze toestemming op elk moment intrekken. Bekijk onze privacyverklaring voor meer informatie.
Zoals gezegd is de Product owner verantwoordelijk voor een initiële Product Backlog. En dat is vaak best nog wel een klus. Een User Story workshop biedt dan wel eens uitkomst. In principe nodig je dan de betrokken stakeholders uit om User Stories te komen maken. Vaak eindigt dit in enorm veel User Story’s—soms dezelfde en vaak variaties op een thema. Soms heel grote Story’s, ook wel Epics genoemd, maar soms ook direct sprintklare versies.
Dat kan bij het maken van een Product Backlog niet alleen ervoor zorgen dat je alle belangrijke Stakeholders in beeld hebt, maar zorgt ook voor betrokkenheid bij de rest van het project. En het is een leuke laagdrempelige kickstart van je project. Immers het doel is letterlijk zoveel mogelijk oogsten, rijp en groen. Het hoeft niet perfect te zijn—en dat levert erg mooie inzichten op.
User Story’s zijn geen verplichting. In de Scrum Guide zul je er niets over vinden. De praktijk leert dat het gebruik ervan wel heel prettig is. Niet alleen kun je zo de behoeften van de eindgebruiker in kaart brengen en prioriteren, maar ook helpt het bij de evaluatie van het geleverde in de review. Door het gebruik van User Story’s kunnen teams zich beter richten op het leveren van de juiste waarde aan de gebruiker door het ontwikkelen van zaken die beter aansluiten bij hun verwachtingen en wensen. Het format is eenvoudig te gebruiken; zo kan het team effectief User Story’s schrijven en refinen.
Meer weten over User story’s? maak het mee in een training of neem contact met ons op.