Sådan skriver du bedre brugerhistorier med agurker (inkl. skabelon)

Brugerhistorier er en Agile-teknik til at definere produktfunktionalitet og -krav. De fokuserer på at fortælle en historie om en handling, som en bruger vil udføre, og hvad forventningen er, når det lykkes. Konceptet med brugerhistorier er meget udbredt, men det kan være ret svært at fortælle gode historier.

Brugerhistorier har dog været lidt i modvind de sidste par år, da de er lidt forsimplede og mangler empati for brugeren.

Gode nyheder – der findes en bedre måde! De hedder agurker, men i modsætning til syltede agurker er de ikke kommet for at gøre dit liv surt. (Medmindre du elsker syltede agurker, formoder jeg!) 🥒.

TL;DR

Hvis du har lidt travlt, er her TL;DR (selvom jeg vil opfordre dig til at læse videre for at få adgang til skabelonerne!)

• Brugerhistorier fokuserer på brugeren, ikke på produktet.
• Skitsér dine personaer for at tilføje kontekst.
• Tilføj empati til dine historier for at forstå handlinger og motivationer.
• Agurker: en bedre måde at skrive historier på.
• Brug agurker til at fokusere på resultater, ikke kun output.

Hvad er brugerhistorier?

Brugerhistorier er korte, enkle beskrivelser af en løsning, som dit team har fundet frem til, fortalt fra perspektivet af den person, der skal udføre interaktionen. De er en del af et større epos, der beskriver det faktiske problem, der skal løses, og hvorfor du løser det.

Det operative ord her er bruger, hvilket betyder, at en brugerhistorie sætter fokus på brugeren, ikke produktet.

En user story fokuserer normalt på tre områder:

• Som en(hvem)
• Jeg vil gerne(hvad)
• Så det(hvorfor)

Alt dette efterfølges normalt af acceptkriterier, som definerer, hvordan du ved, om interaktionen er vellykket.

Hvem: Brug personas til at skitsere brugerhistorier

Hvis du endnu ikke har defineret eller forstået dine brugere, bør du virkelig ikke skrive brugerhistorier. Start med at gå på opdagelse, kortlæg en kunderejse, og skab relevante brugerpersonaer, som kan hjælpe dig med at definere historierne yderligere.

En persona kan hjælpe dig med at forstå og give kontekst til “hvem” i brugerhistorien – med andre ord, hvem der udfører denne interaktion.

Dette er vigtigt, da du uundgåeligt vil have forskellige kundesegmenter, roller og tilladelser involveret, så det er vigtigt at definere disse interaktioner for at imødekomme de forskellige typer brugere.

Hvad: Interaktion med brugerhistorier

‘Hvad’ i en user story fokuserer på selve interaktionen. Det vanskelige her er at sikre, at dit “hvad” fokuserer på, hvad brugeren skal gøre, i modsætning til hvad brugeren ønsker at gøre, og det er her, den typiske historieskabelon falder lidt fra hinanden.

For at tilføje en smule empati til selve historien er det vigtigt at fremhæve, hvordan brugeren kan føle sig, når han interagerer med en bestemt handling.

For eksempel er der ingen, der har lyst til at indtaste et kompliceret password med store bogstaver, specialtegn og en minimumslængde – men de ved, at de burde. I dette tilfælde er det noget, som brugeren er forpligtet til at gøre.

Hvorfor: Årsagen til brugerhistoriens handling

Den tredje del af brugerhistorieskabelonen er “hvorfor” – det vil sige, hvorfor brugeren ønsker (eller er forpligtet til) at udføre en bestemt handling.

For at vende tilbage til vores tidligere eksempel med indtastning af adgangskoder:

Som administrator er jeg forpligtet til at oprette en kompliceret adgangskode, så min konto er sikker.

Vi forstår nu historiens hvem, hvad og hvorfor – men der er et problem her. Det mangler stadig empati og kontekst, for lad os være ærlige: Ingen ønsker, at komplicerede adgangskoder skal være et krav, men vi ønsker alle sikre konti.

Når de testede dette, ville QA-teamet blot stoppe med at tjekke, om adgangskoden var sikker, ikke om processen var frustrerende for brugeren.

Indtast Gherkin-brugerhistorieskabelonen

Gherkins er en måde at tilføje til brugerhistorier og give et komplet scenarie, der hjælper udviklere og testere med at forstå både resultatet og outputtet af en bestemt brugerinteraktion.

1. Scenario – den adfærd, du vil beskrive
2. Given – scenariets begyndelsestilstand
3. When – en specifik handling, som brugeren udfører
4. Then – et testbart resultat, som regel forårsaget af handlingen i When
5. And – dette fortsætter en af de andre tre operationer, hvis det er nødvendigt

Tag det tidligere beskrevne password-scenarie:

1. Når du indstiller en adgangskode (Scenario),
2. Given at jeg er kontoadministrator,
3. WhenJeg indtaster en adgangskode i adgangskodefeltet,
4. ThenJeg burde være blevet advaret om kravene til adgangskoden,
5. And Jeg burde have lov til at lave rettelser med det samme,
6. Then at jeg kan oprette en sikker konto.

Vi har nu et fuldt billede af, hvem der udfører den specifikke handling, og hvad kravene er til acceptkriterierne, og teamet ved, hvilke potentielle frustrationer der kan være, så de kan sikre, at processen flyder mere glat.

Generelt er produktchefen eller produktejeren ansvarlig for at skrive Gherkin-historierne, hvilket skaber bedre kommunikation mellem resten af teamet og sikrer, at alle fokuserer på resultater og ikke kun output.

Hvad er dine foretrukne måder at skitsere historier på? Giv mig besked! ✌️