samen
werken
Wat is een User Story?
Een User Story is een korte, eenvoudige beschrijving van een behoefte van de eindgebruiker. Een kort verhaaltje, geschreven vanuit het oogpunt van die eindgebruiker. Een User Story is geen functionele beschrijving, maar maakt duidelijk wat een eindgebruiker wil, of nodig heeft en ook waarom dat nodig is. Bijvoorbeeld:
- Als zorgverlener, wil ik inzicht in de medicatiehistorie van de patiënt, zodat ik bij twijfel de nieuw voorgeschreven dosering gemakkelijk kan verifiëren.
User Stories worden meestal geschreven door de Product Owner en horen thuis op de Product Backlog. (De geprioriteerde werkvoorraad.) In een Agile project worden User Stories door de Developers (voorheen het Development Team genoemd) opgepakt uit de Product Backlog, uitgewerkt en opgeleverd. Met het opleveren van een User Story wordt een stukje ‘waarde’ geleverd voor de eindgebruiker. Alle User Stories op de Product Backlog vertegenwoordigen samen de totale ‘waarde’ die binnen een project kan worden opgeleverd.
Wat is ‘waarde’ in een User Story?
‘Waarde’ is een breed begrip, maar binnen een Agile project is ‘Waarde’ in ieder geval datgene wat tegemoetkomt aan de klantbehoefte. Anders gezegd: iets dat daadwerkelijk bijdraagt aan het oplossen van het daadwerkelijke ‘probleem’ van de eindgebruiker. Het leveren van waarde voor de eindgebruiker/klant heeft binnen een Agile project altijd de hoogste prioriteit. Deze waarde kan vanwege de complexiteit meestal niet in één keer geleverd worden. Een goede Product Backlog bestaat daarom uit een heleboel kleinere User Stories, die onderling ook nog zijn geprioriteerd. User Stories die op dit moment de meeste waarde leveren, staan bovenaan. User Stories waarvan (nog) niet duidelijk is wat de waarde is, worden niet opgepakt door het team.
User Stories zijn géén ‘Acceptatiecriteria’
Een veel voorkomend misverstand is dat een User Story hetzelfde is als de acceptatiecriteria, ook wel ‘requirements’ of ‘productvereisten’ genoemd. Acceptatiecriteria scheppen een (functioneel) kader waarmee de Developers aan het werk kunnen. Laten we beginnen met wat voorbeelden van acceptatiecriteria bij de eerder beschreven User Story:
- Data moeten digitaal beschikbaar zijn
- Data moeten consistent en up-to-date zijn
- Data moeten conform AVG beschermd én afgeschermd zijn
- Data formats moeten platform-agnostisch zijn
Zoals gezegd staan de ‘klant’ en de ‘waarde’ voor de klant centraal in het Agile project. De ervaring leert echter dat een lijst met Acceptatiecriteria alleen niet voldoende inzicht geeft in die waarde, omdat de context eromheen ontbreekt. De User Story is bedoeld om juíst die context te duiden, waardoor de Developers de acceptatiecriteria kunnen interpreteren vanuit het klantperspectief. Om dat te verduidelijken kijken we nog een keer naar structuur van de User Story. Die structuur is heel eenvoudig.
De structuur van de User Story Wie? Wat? en Waarom?
- Als: (klant)
- Wil ik: (beschrijving van datgene dat ontwikkeld moet worden)
- Zodat ik: (beschrijving van de reden waarom dat ontwikkeld moet worden)
Als zorgverlener, wil ik inzicht in de medicatiehistorie van de patiënt, zodat ik bij twijfel de nieuw voorgeschreven dosering gemakkelijk kan verifiëren.
Met deze structuur is direct duidelijk voor Wie er iets ontwikkeld wordt, Wat er ontwikkeld wordt en wat de ‘Waarde’ is die daarmee geleverd moet worden. Door het duiden van de context geeft een User Story richting aan de ontwikkeling. De acceptatiecriteria stellen de randvoorwaarden aan het resultaat van de ontwikkeling.
Een User Story beschrijft de waarde, niet de oplossing
In bovenstaand voorbeeld is duidelijk dat het om ‘inzicht’ gaat. Inzicht dat nodig is om de juiste behandeling van de patiënt te kunnen waarborgen. Het waarborgen van de juiste behandeling is de uiteindelijke waarde die geleverd moet worden. Hoe dat ‘inzicht’ dan precies wordt vormgegeven, de feitelijke innovatie, is uiteindelijk aan de Developers. Dat zijn tenslotte de experts die niet voor niets in het Scrum Team zitten. Een goede Product Owner zorgt er voor dat de User Stories over de ‘waarde’ gaan en niet in de oplossing gaan zitten. Zo blijft er ruimte voor het team om tot innovatie te komen.
Wanneer schrijf je een User Story?
User Stories worden geschreven vanuit de visie die is ontwikkeld rond het Agile project. Nadat de projectvisie is geformuleerd, kan de Product Owner ervoor kiezen om een User Story workshop te organiseren. Teamleden die een relevante bijdrage kunnen leveren, nemen hieraan deel. In een goede Workshop komen de User Stories tot stand door middel van een gezamenlijke conversatie tussen de deelnemers. Deze conversatie tussen Product Owner en team is van cruciaal belang, omdat dat input levert vanuit meerdere invalshoeken. Diversiteit leidt tot betere User Stories en uiteindelijk tot meer innovatie.
User Stories in verschillende formaten
User Stories komen voor in verschillende formaten. Een User Story kan een volledig product beschrijven, maar ook beperkt zijn tot een specifiek onderdeel van dat product. Een grote User Story wordt een ‘Epic’ genoemd. Een Epic is per definitie te groot om op te pakken en in één keer op te leveren. Daarvoor moet de Epic eerst worden opgeknipt in kleinere User Stories, die klein genoeg zijn om elk in één sprint te passen. Hieronder geven we een voorbeeld van hoe het opknippen van grote User Stories in zijn werk kan gaan:
Als reisorganisatie willen wij, naast de huidige autovakanties, ook vliegvakanties gaan aanbieden, zodat we een breder marktsegment kunnen bedienen. Met daarbij de acceptatiecriteria:
- Europese bestemmingen
- Trans-Atlantische bestemmingen
- ZO-Aziatiatische bestemmingen
De acceptatiecriteria van deze Epic kunnen als zelfstandige User Stories dienen, met ieder eigen acceptatiecriteria:
- Italië
- Spanje
- Portugal
Ook dit is een Epic met acceptatiecriteria die als zelfstandige User Stories door kunnen gaan:
Als reisorganisatie willen wij, naast de huidige autovakanties, ook vliegvakanties naar Italië gaan aanbieden, zodat we een breder marktsegment kunnen bedienen. Met daarbij de acceptatiecriteria:
- Milaan
- Rome
- Venetië
En zo verder, tótdat je User Stories hebt met een grootte die in één Sprint zijn op te leveren.
Product Backlog
Door vanuit een duidelijke visie User Stories te schrijven en deze vervolgens te verfijnen, kan uiteindelijk een Product Backlog worden samengesteld die, met de kennis en inzichten van dát moment, zoveel mogelijk ‘waarde’ vertegenwoordigt. Deze initiële Product Backlog dient als vertrekpunt voor het Agile project. Een Agile team werkt iteratief en evalueert en valideert de geleverde waarde voortdurend. Hierdoor leert het team steeds meer over wat ‘waarde’ nou écht is, binnen de context van het project. Dit voortschrijdend inzicht zie je terug in een Product Backlog die voortdurend aangepast en/of aangevuld wordt met nieuwe User Stories, of bestaande User Stories die worden herschreven.
Het bijwerken van de Product Backlog door: het kleiner maken, aanscherpen, van detail voorzien, aanpassen en (her)prioriteren van User Stories, wordt Product Backlog Refinement genoemd. Product Backlog Refinement is de verantwoordelijkheid van de Product Owner en gaat door totdat de maximale waarde uit de Product Backlog is geleverd. Als de maximale waarde uit de Product Backlog is geleverd en de kosten niet meer opwegen tegen de baten, dan komt ook het project ten einde.
Wij kunnen jouw organisatie ook helpen om op een goede manier User Stories te schrijven. Neem eens een kijkje bij ons trainingsaanbod om te zien welke training bij jouw organisatie past.
Ook interessant:
Volg ons op LinkedIn (we delen onze blogs met je)
