Scrum Guide | 21. Misstag med användarberättelser

Användarberättelser beskriver hur en ny produktfunktionalitet fungerar på vardagligt eller affärsmässigt språk. Förberedelsen av dem tar dock mycket tid, ansträngning och eftertanke. I dagens inlägg påpekar vi de vanligaste misstagen med användarberättelser och föreslår hur man kan hantera dem.

De vanligaste misstagen med användarberättelser – innehållsförteckning:

1. Introduktion
2. Problem med 3W
3. Problem med 3C
4. Misstag med användarberättelser – Sammanfattning

Introduktion

En användarberättelse kan vara ett utmärkt verktyg för att motivera teamet att föreslå nya lösningar på problem som presenteras ur användarens perspektiv. Vi skrev om vad en användarberättelse är i en separat artikel. Och i denna artikel introducerade vi INVEST, som är en populär metod för att skriva bra användarberättelser. Idag kommer vi att fokusera på misstag med användarberättelser.

Problem med 3W

En korrekt användarberättelse besvarar frågorna:

• Vem? (Vem är den målgrupp som produkten riktar sig till?)
• Vad? (Vilka funktioner har produkten, och vad kan den göra?)
• Varför? (Vilket syfte tjänar den?)

Problemen kan dock följa med svaren på var och en av dessa frågor. Det minst vanliga problemet är tvivlet om vad som bör förändras i produkten som svar på kundens behov. Därför kommer vi att fokusera på problem som rör Vem? och Varför?

Vem – användarpersona

Ett av de vanligaste misstagen när man skapar användarberättelser är att inte besvara frågan tillräckligt exakt: för vem? Med andra ord, vem är användaren som den planerade förändringen är avsedd för?

Ofta är ett generiskt svar som pekar på kunden eller slutanvändaren som mottagare av förändringen inte tillräckligt. Lösningen på detta problem är att föreställa sig mottagaren som en specifik persona. En persona är en modellbild av den målgrupp som produkten riktar sig till. Med andra ord är en persona en representation av den person som kommer att använda produkten på ett specifikt sätt.

Efter att ha analyserat din användarberättelse kan du upptäcka att den berättar historier om olika personer samtidigt. Om det finns många målgrupper är det värt att överväga att dela upp användarberättelsen i mindre fragment för att undvika motstridiga, ömsesidigt uteslutande eller helt enkelt ineffektiva åtgärder.

Varför? – ett dåligt definierat mål

Ibland blir den sista delen av användarberättelsen källan till problem. Den bör specificera det affärsvärde som förändringarna som görs under genomförandet av användarberättelsen har. Ta en titt på ett exempel på misstag med användarberättelser där beskrivningen av ytterligare funktionalitet ersätter målet:

Som kund vill jag köpa en magisk stav med ett klick eftersom jag vill köpa en flygande matta nästa vecka.

Istället för att ge anledningen till att köpa den magiska staven, lägger denna användarberättelse till ytterligare en punkt på den potentiella kundens inköpslista. Därför, när du förbereder en användarberättelse, glöm inte bort anledningarna till förändringar i produktens funktionalitet.

Problem med 3C

Vi kan dela upp processen för att arbeta med användarberättelser i tre steg som kallas 3C:

• Kort – Kortet på vilket användarberättelsen sparas
• Samtal – Ett samtal inom Scrum-teamet om användarberättelsekortet
• Bekräftelse – definiera acceptanskriterier som bekräftar att en uppgift har slutförts

Fel kan uppstå på något av dessa, vilket vi beskriver nedan.

Kort

Minnekortet som lagrar användarberättelsen har en begränsad kapacitet. Därför rör de vanligaste problemen längden och volymen av användarberättelsen. Användarberättelsen behöver sammanhang och inget svammel, som man säger, till en sådan precisionsgrad att varje ord räknas.

Detta beror på att problemet med användarberättelsekortet har två dimensioner. Den ena är hur den formuleras: koncis och innehållande en nödvändig minimi mängd av uppräkning. Den andra är den faktiska storleken på användarberättelsen. En allmän mening kan uttrycka ett stort antal uppgifter som inte kan slutföras under en enda sprint.

Samtal

Formuleringen av användarberättelsen i en mening är utgångspunkten för ett samtal med utvecklingsteamet. Därför är det felaktigt att behandla den som en beskrivning av uppgiften att utföra. Det hindrar möjligheten till förhandlingar och diskussioner om olika sätt att genomföra den. Användarberättelsen bör inte behandlas som en beskrivning av krav för ny produktfunktionalitet, utan snarare som en inbjudan att påbörja ett samtal om specifika tekniska lösningar som kommer att leda till realiseringen av det affärsvärde som definieras av användarberättelsen.

Bekräftelse

Vi har skrivit om acceptanskriterierna som måste definieras för varje användarberättelse i detalj i texten som beskriver vad en användarberättelse är. Ett av de vanliga misstagen är dock bristen på tydlighet i prestationskriterierna.

En välskriven användarberättelse innehåller en beskrivning av den situation där den implementeras. Dess test är att användaren drar nytta av den nya funktionalitet som skapats av utvecklingsteamet.

Ett användbart verktyg för att validera användarberättelsen är att utveckla ett acceptanstest. Detta finns vanligtvis på andra sidan av kortet som innehåller användarberättelsen.

Misstag med användarberättelser – Sammanfattning

När man förbereder och tillämpar användarberättelser är det värt att följa följande regler:

• Identifiera noggrant den användare som påverkas av förändringen
• Definiera tydligt syftet med att bygga ny produktfunktionalitet
• Håll dess volym så kort som möjligt
• Behandla användarberättelsen som en utgångspunkt för diskussioner med utvecklingsteamet
• Fastställ tydliga regler för acceptans

Om du gillar vårt innehåll, gå med i vår aktiva gemenskap av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.