Hur man skriver bättre användarberättelser med gurkor (mall inkluderad)

Användarberättelser är en Agile-teknik för att definiera produktfunktionalitet och krav. De fokuserar på att berätta en historia om en åtgärd som en användare kommer att vidta och vad förväntningarna är när den lyckas. Begreppet user stories används ofta, men att berätta bra historier kan vara ganska svårt.

Användarberättelser har dock fått sig en törn de senaste åren, eftersom de är något förenklade och saknar empati för användaren.

Goda nyheter – det finns ett bättre sätt! De kallas gurkor, men till skillnad från saltgurkan är de inte här för att göra ditt liv surt. (Om du inte är en pickle-älskare, antar jag!) 🥒

TL;DR

Om du har lite bråttom, här är TL;DR (även om jag skulle uppmuntra dig att fortsätta läsa för att få tillgång till mallarna!)

• User stories fokuserar på användaren, inte på produkten.
• Beskriv dina personas för att ge sammanhang.
• Lägg till empati i dina berättelser för att förstå handlingar och motiv.
• Gurkor: ett bättre sätt att skriva berättelser.
• Använd gurkor för att fokusera på resultat, inte bara prestationer.

Vad är användarberättelser?

Användarberättelser är korta, enkla beskrivningar av en lösning som ditt team har kommit fram till, berättade ur perspektivet för den person som spelar ut interaktionen. De är en del av en större epik som beskriver det faktiska problemet som ska lösas och varför du löser det.

Det operativa ordet här är användare, vilket innebär att en användarberättelse sätter fokus på användaren, inte produkten.

En user story fokuserar vanligtvis på tre områden:

• Som(vem)
• Jag vill(vad)
• Så att(varför)

Allt detta följs vanligtvis av acceptanskriterier, som definierar hur du vet om interaktionen är framgångsrik.

Vem: Använda personas för att beskriva användarberättelser

Om du ännu inte har definierat eller förstått dina användare bör du verkligen inte skriva användarberättelser. Börja med att ta reda på mer, kartlägg en kundresa och skapa relevanta användarprofiler som hjälper dig att definiera dessa berättelser ytterligare.

En persona kan hjälpa dig att förstå och ge sammanhang till “vem” i användarberättelsen – med andra ord, vem som genomför denna interaktion.

Detta är viktigt eftersom du oundvikligen kommer att ha olika kundsegment, roller och behörigheter involverade, så det är viktigt att definiera dessa interaktioner för att tillgodose de olika typerna av användare.

Vad: Interaktioner mellan användarberättelser

“Vad” i en user story fokuserar på själva interaktionen. Det svåra här är att se till att ditt “vad” fokuserar på vad användaren måste göra, i motsats till vad användaren vill göra, och det är här den typiska berättelsemallen faller lite isär.

För att lägga till lite empati i själva berättelsen är det viktigt att belysa hur användaren kan känna sig när den interagerar med en viss åtgärd.

Ingen vill t.ex. ange ett komplicerat lösenord med stor bokstav, specialtecken och en minimilängd – men de vet att de borde göra det. I det här fallet är det något som användaren måste göra.

Varför: Anledningen till åtgärden i användarberättelsen

Den tredje delen av mallen för användarberättelsen är “varför” – det vill säga varför användaren vill (eller måste) utföra en viss åtgärd.

Återgå till vårt tidigare exempel med att ange lösenord:

Som administratör måste jag skapa ett komplicerat lösenord så att mitt konto är säkert.

Vi förstår nu vem, vad och varför i historien – men det finns ett problem här. Detta saknar fortfarande empati och sammanhang, för låt oss vara ärliga, ingen vill att komplicerade lösenord ska vara ett krav, men vi vill alla ha säkra konton.

När QA-teamet testade detta skulle de helt enkelt stanna vid att kontrollera om lösenordet är säkert, inte om processen var frustrerande för användaren.

Ange mallen för användarberättelsen för Gherkin

Gurkor är ett sätt att lägga till användarberättelser och ge ett fullständigt scenario som hjälper utvecklare och testare att förstå både resultatet och effekten av en viss användarinteraktion.

1. Scenario – det beteende som du kommer att beskriva
2. Given – scenariots utgångsläge
3. When – en specifik åtgärd som användaren vidtar
4. Then – ett testbart resultat, vanligtvis orsakat av åtgärden i When
5. And – detta fortsätter med någon av de andra tre åtgärderna vid behov

Ta lösenordet scenario som tidigare beskrivits:

1. När du ställer in ett lösenord (Scenario),
2. Given att jag är kontoadministratör,
3. WhenJag anger ett lösenord i lösenordsfältet,
4. ThenJag bör varnas för lösenordskraven,
5. And Jag borde få göra korrigeringar direkt,
6. Then att jag kan skapa ett säkert konto.

Vi har nu en fullständig bild av vem som utför den specifika åtgärden och vilka kraven är för acceptanskriterierna, och teamet vet vilka potentiella frustrationer det kan finnas så att de kan se till att processen flyter smidigare.

I allmänhet är produktchefen eller produktägaren ansvarig för att skriva ut Gherkin-berättelserna, vilket skapar bättre kommunikation mellan resten av teamet och ser till att alla fokuserar på resultat, inte bara output.

Vilka är dina favoritsätt att skissa upp berättelser? Låt mig veta! ✌️