Scrum Guide | 19. Användarberättelser – vad är de?

Användarberättelse är en kort beskrivning av en ny produktfunktion eller dess förbättring. Den innehåller ingen teknisk lösning utan tar upp frågor som rör funktionaliteten: Vem är användaren? Vad gör produkten? Och vad är dess syfte? Användarberättelsen beskriver produkten på vardagligt eller affärsmässigt språk, även om den också pekar på Scrum-teamets uppgifter som syftar till att förbättra teamets prestation.

Vad är användarberättelser? – innehållsförteckning:

1. Introduktion
2. Användarberättelse. Vems berättelse är det?
3. Hur använder man användarberättelser?
4. Acceptanskriterier
5. Sammanfattning

Introduktion

Användarberättelse är det vanligaste sättet att formulera uppgifter som utförs av Scrum-teamet. En enda användarberättelse definierar en liten funktionalitet av produkten. Den beskriver det minsta meningsfulla, delmål för produkten. Av denna anledning är användarberättelser mycket korta.

Användarberättelser skapas under hela tiden av arbetet med produkten. De skapas kontinuerligt, från det ögonblick beslutet att påbörja arbetet fattas, till realiseringen av produktmålet.

Att skapa användarberättelser är en produktägares uppgift. Baserat på ett samtal med en kund formulerar de svar på frågor som möjliggör skapandet av en användarberättelse och för in dem i produktbackloggen. Men användarberättelser speglar inte bara kundens behov.

Användarberättelse. Vems berättelse är det?

Scrum-teamet skapar en användarberättelse för att definiera användarens behov, och därför skrivs den på affärsspråk. Med andra ord indikerar den de fördelar som dess implementering kommer att ge produktanvändaren. Men i produktbackloggen kan det också finnas användarberättelser som beskriver utvecklingsteamets behov, till exempel att förbättra arbetsflödet mellan utvecklarna, eller beskriva produktägarens behov, till exempel att organisera produktbackloggen. I sådana fall är användaren i användarberättelsen utvecklaren och produktägaren.

Du kan beskriva en användarberättelse genom att svara på 3W-frågorna:

• Vem?
• Gör Vad?
• Varför?

Användarberättelsen innehåller då en formel:

Som en [användartyp], vill jag [göra vad?] För att [varför?].

Exempel på användarberättelser om funktionaliteten hos en webbutik skrivna i denna form illustreras i tabellen nedan:

Denna formel möjliggör inte bara att formulera en användarberättelse utan också att relativt enkelt översätta tekniskt språk till affärsspråk och tvärtom. Som ett resultat ser både utvecklare och intressenter tydligt målet och stegen i dess framsteg. Vi kommer också att ta upp skapandet av bra användarberättelser med hjälp av INVEST-metoden i en separat artikel i Scrum Guide-serien.

Hur använder man användarberättelser?

Att skapa en schematisk användarberättelse är bara början. De är signaler och utgångspunkter för diskussioner om problem och deras lösningar. Diskussioner om användarberättelser äger rum under sprintplaneringen för att reda ut vilka tekniska frågor utvecklingsteamet kommer att lägga till i sprintbackloggen.

Typiskt sett, i det fysiska rummet, är användarberättelser skrivna på små, färgglada kort som är fästa på arbetsplatsen. Men i det digitala rummet fungerar digitala whiteboards, som delas av Scrum-teamet, bäst.

Att spara användarberättelser på detta sätt har flera fördelar eftersom:

• Betonar autonomin hos varje användarberättelse – varje har en separat ram och kan utföras oberoende av de andra
• Betonar dynamiken hos användarberättelser – ordningen för deras genomförande omförhandlas av Scrum-teamet och den aktuella ordningen för genomförande är synlig på tavlan tack vare den fysiska arrangemanget av kort med användarberättelser
• Fungerar som en påminnelse – tack vare den visuella representationen av användarberättelser har Scrum-teamet en vägskylt i sikte för att påminna dem om målet när de skapar detaljerade lösningar.

Utvecklingsteamet uppskattar den erforderliga insatsen för att slutföra en användarberättelse i dagar, arbetstimmar eller Story Points.

Acceptanskriterier

En användarberättelse måste ha vissa acceptanskriterier i det ögonblick den accepteras för utveckling av utvecklingsteamet. Acceptanskriterierna bestämmer vid vilken tidpunkt arbetet med en användarberättelse kan anses vara avslutat.

På så sätt vet både kunden och utvecklarna hur deras arbete kommer att översättas till affärsvärde. Typiskt sett anses en användarberättelse vara avslutad när den användare som specificerats i den kan utföra den beskrivna åtgärden. Med hjälp av exemplet ovan, ta en titt på denna användarberättelse med innehållet:

En kund kan köpa en magisk stav med ett enda klick.

Den är avslutad när en fungerande “Köp nu”-knapp visas på webbutikens sida, som använder standardbetalnings- och fraktinformation för den inloggade användaren.

Sammanfattning

En användarberättelse är en kortfattad beskrivning av en ny produktfunktion eller förbättring. Den fungerar som det minsta målet uttryckt på affärsspråk, det vill säga, ur perspektivet av affärsvärde och användaren. Den hjälper till att tydligt definiera den uppgift som ska utföras samt kriterierna för dess slutförande.

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