Scrum Gids | 21. Fouten bij User Stories

Gebruikersverhalen beschrijven hoe een nieuwe productfunctionaliteit werkt in alledaagse of zakelijke taal. De voorbereiding ervan kost echter veel tijd, moeite en denkwerk. In de bijdrage van vandaag wijzen we op de meest voorkomende fouten in gebruikersverhalen en suggereren we hoe hiermee om te gaan.

De meest voorkomende fouten in gebruikersverhalen – inhoudsopgave:

1. Inleiding
2. Problemen met 3W
3. Problemen met 3C
4. Fouten in gebruikersverhalen – Samenvatting

Inleiding

Een gebruikersverhaal kan een geweldig hulpmiddel zijn om het team te motiveren om nieuwe oplossingen voor problemen vanuit het perspectief van de gebruiker voor te stellen. We hebben in een apart artikel geschreven over wat een gebruikersverhaal is. En in dit artikel hebben we INVEST geïntroduceerd, wat een populaire methode is voor het schrijven van goede gebruikersverhalen. Vandaag zullen we ons richten op fouten in gebruikersverhalen.

Problemen met 3W

Een goed gebruikersverhaal beantwoordt de vragen:

• Wie? (Wie is de doelgebruiker van het product?)
• Wat? (Welke mogelijkheden heeft het product en wat kan het doen?)
• Waarom? (Wat is het doel ervan?)

Echter, problemen kunnen gepaard gaan met de antwoorden op elk van deze vragen. Het minst voorkomende probleem is de twijfel over wat er in het product moet veranderen als reactie op de behoeften van de klant. Daarom zullen we ons richten op problemen met betrekking tot Wie? en Waarom?

Wie – gebruikerspersona

Een van de meest voorkomende fouten bij het maken van gebruikersverhalen is het niet nauwkeurig genoeg beantwoorden van de vraag: voor wie? Met andere woorden, wie is de gebruiker voor wie de geplande wijziging bedoeld is?

Vaak is een generiek antwoord dat wijst op de klant of eindgebruiker als ontvanger van de wijziging niet genoeg. De oplossing voor dit probleem is om de ontvanger voor te stellen als een specifieke persona. Een persona is een modelbeeld van de doelklant. Met andere woorden, een persona is een representatie van de persoon die het product op een specifieke manier zal gebruiken.

Na het analyseren van je gebruikersverhaal, kun je ontdekken dat het de verhalen van verschillende mensen tegelijkertijd vertelt. Als er veel doelgebruikers zijn, is het de moeite waard om het gebruikersverhaal op te splitsen in kleinere fragmenten om tegenstrijdige, wederzijds uitsluitende of gewoon ineffectieve acties te vermijden.

Waarom? – een slecht gedefinieerd doel

Soms wordt de laatste sectie van het gebruikersverhaal de bron van problemen. Het moet de zakelijke waarde van de wijzigingen die tijdens de uitvoering van het gebruikersverhaal worden aangebracht, specificeren. Kijk eens naar een voorbeeld van fouten in gebruikersverhalen waarbij de beschrijving van extra functionaliteit het doel vervangt:

Als klant wil ik met één klik een toverstok kopen omdat ik volgende week een vliegend tapijt wil kopen.

In plaats van de reden voor het kopen van de toverstok te geven, voegt dit gebruikersverhaal een ander item toe aan de boodschappenlijst van de potentiële klant. Vergeet daarom bij het voorbereiden van een gebruikersverhaal niet de redenen voor wijzigingen in de functionaliteit van het product.

Problemen met 3C

We kunnen het proces van werken met gebruikersverhalen opdelen in drie fasen die de 3C’s worden genoemd:

• Kaart – De kaart waarop het gebruikersverhaal is opgeslagen
• Gesprek – Een gesprek binnen het Scrum-team over de gebruikersverhaalkaart
• Bevestiging – het definiëren van acceptatiecriteria die bevestigen dat een taak is voltooid

Fouten kunnen zich op elk van deze voordoen, die we hieronder beschrijven.

Kaart

De geheugenkaart die het gebruikersverhaal opslaat, heeft een beperkte capaciteit. Daarom hebben de meest voorkomende problemen betrekking op de lengte en het volume van het gebruikersverhaal. Het gebruikersverhaal heeft samenhang nodig en geen omwegen, zoals men zegt, tot zo’n nauwkeurige mate dat elk woord telt.

Dit komt omdat het probleem van de gebruikersverhaalkaart twee dimensies heeft. De ene is de manier waarop het is geformuleerd: bondig en met een noodzakelijke minimum hoeveelheid opsomming. De tweede is de werkelijke grootte van het gebruikersverhaal. Eén algemene zin kan een enorm aantal taken uitdrukken die niet tijdens een enkele sprint kunnen worden voltooid.

Gesprek

De formulering van het gebruikersverhaal in één zin is het startpunt voor een gesprek met het ontwikkelingsteam. Daarom is het onjuist om het te beschouwen als een beschrijving van de uit te voeren taak. Het maakt de mogelijkheid van onderhandelingen en discussie over verschillende manieren van uitvoering onmogelijk. Een gebruikersverhaal moet niet worden behandeld als een beschrijving van vereisten voor nieuwe productfunctionaliteit, het is eerder een uitnodiging om een gesprek te beginnen over specifieke technische oplossingen die zullen leiden tot de realisatie van de zakelijke waarde die door het gebruikersverhaal is gedefinieerd.

Bevestiging

We hebben in detail geschreven over de acceptatiecriteria die voor elk gebruikersverhaal moeten worden gedefinieerd in de tekst die beschrijft wat een gebruikersverhaal is. Een van de veelvoorkomende fouten is echter het gebrek aan vaagheid van prestatiecriteria.

Een goed geschreven gebruikersverhaal bevat een beschrijving van de situatie waarin het wordt geïmplementeerd. De test is dat de gebruiker gebruikmaakt van de nieuwe functionaliteit die door het ontwikkelingsteam is gecreëerd.

Een nuttig hulpmiddel voor het valideren van het gebruikersverhaal is om een acceptatietest te ontwikkelen. Dit staat meestal aan de andere kant van de kaart met het gebruikersverhaal.

Fouten in gebruikersverhalen – Samenvatting

Bij het voorbereiden en toepassen van gebruikersverhalen is het de moeite waard om je aan de volgende regels te houden:

• Identificeer nauwkeurig de gebruiker die door de wijziging wordt beïnvloed
• Definieer duidelijk het doel van het bouwen van nieuwe productfunctionaliteit
• Houd het volume zo kort als mogelijk
• Behandel het gebruikersverhaal als een startpunt voor discussies met het ontwikkelingsteam
• Stel duidelijke regels voor acceptatie vast

Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.