Gebruikersverhaal

Een user story is een korte beschrijving van een vereiste, geformuleerd vanuit het perspectief van de persoon die er baat bij heeft. Traditioneel wordt deze beschreven in de vorm van een rol, een gewenste functionaliteit en de reden waarom deze gewenst is. Het concept is ontstaan ​​in de wereld van extreme programming en is uitgegroeid tot de dominante manier om werk in iteratieve ontwikkeling te beschrijven.

Het doel ervan wordt vaak verkeerd begrepen. Het verhaal is geen specificatie; het is een herinnering om een ​​gesprek aan te gaan. De oorspronkelijke formulering beschreef verhalen als placeholders voor een discussie tussen de mensen die de functionaliteit willen en de mensen die deze gaan bouwen, en de geschreven tekst dient om ervoor te zorgen dat de discussie plaatsvindt, niet om deze te vervangen. Teams die de kaart als een complete vereiste beschouwen, hebben het format overgenomen en het mechanisme laten vallen.

De redenclausule is het meest waardevolle element, maar ook het element dat het vaakst slordig wordt geformuleerd. Door aan te geven waarom een ​​bepaalde functionaliteit gewenst is, kan een team een ​​andere, vaak betere oplossing voor dezelfde behoefte voorstellen. Bovendien maakt het mogelijk om taken eerlijk te deprioriteren wanneer de onderliggende reden zwak blijkt te zijn. Verhalen waarvan de redenclausule slechts de functionaliteit herhaalt, zoals "een knop nodig hebben om erop te kunnen drukken", communiceren niets en sluiten de mogelijkheid tot een zinvol gesprek uit.

De omvang is belangrijk omdat een user story binnen een iteratie afgerond moet kunnen worden en iets moet opleveren dat de gebruiker daadwerkelijk kan ervaren. Te grote user stories kunnen niet worden afgerond of beoordeeld, terwijl user stories die zijn opgedeeld in technische lagen, zoals het afzonderlijk bouwen van een databasetabel of een interfacecomponent, afzonderlijk niets waarneembaars opleveren. Verticale slicing, waarbij elke user story door elke laag heen snijdt om een ​​dunne maar complete functionaliteit te creëren, zorgt ervoor dat de mogelijkheid tot demonstratie en leren behouden blijft.

Het formaat is eerder een conventie dan een vereiste, en strikte naleving leidt tot absurditeiten. Technisch werk zonder directe gebruiker, zoals het bijwerken van een afhankelijkheid of het verbeteren van de observeerbaarheid, past niet in het sjabloon en het erin persen creëert een kunstmatige gebruiker die een bijgewerkte bibliotheek wil. Het duidelijk vastleggen van dergelijk werk, met een toelichting op de onderliggende redenen, is eerlijker en nuttiger dan het te verdraaien om aan een formaat te voldoen.

Acceptatiecriteria maken een verhaal toetsbaar en horen er integraal bij, in plaats van een apart onderdeel te zijn. Ze beschrijven de voorwaarden waaronder het verhaal als compleet wordt beschouwd, inclusief de randgevallen en foutpaden die de verhaalstructuur niet toelaat. Zonder acceptatiecriteria wordt de voltooiing een kwestie van mening, en de onenigheid komt meestal pas aan het licht tijdens de beoordeling, wanneer het het duurst is om deze op te lossen.

Verhalen hopen zich op tot achterstanden die onbeheersbaar worden als ze nooit worden opgeschoond. Artikelen die maanden geleden zijn geschreven, beschrijven een product en een markt die sindsdien zijn veranderd, en een achterstand van honderden verhalen is een document dat niemand leest in plaats van een plan. Het periodiek verwijderen van verhalen die realistisch gezien niet zullen worden gerealiseerd, is ongemakkelijk, maar aanzienlijk nuttiger dan ze voor onbepaalde tijd te behouden.

Omdat de waarde afhangt van het gesprek in plaats van het object, wordt de effectiviteit bepaald door de vraag of de juiste mensen deelnemen. In de praktijk wordt het format gebruikt binnen productontwikkeling waarbij de onderliggende behoefte blijkt uit gebruikersonderzoek In plaats van dat het als vanzelfsprekend wordt beschouwd, en organisaties die deze capaciteit intern opbouwen, vestigen de schrijf- en verfijningsprocedure doorgaans binnen een productafdeling zodat verhalen voortkomen uit gevalideerde problemen.