Användarberättelser i Scrum: Allt du behöver veta

Målet är tydligt: ni vill utveckla en produkt som ger kunderna ett högt mervärde. Man vill uppnå ett resultat som teammedlemmar och intressenter är nöjda med. Men hur uppnår man detta mål? Hur kan man uppfylla alla krav på en produkt i små, noggranna steg? 

I Agile har användarberättelser visat sig vara ett effektivt verktyg för detta. De tar dig steg för steg från den första idén till en produkt som är redo för försäljning. Jag kommer att visa dig vad user stories är, hur man skapar dem och hur du kan dra nytta av dem.

Definitionen av användarberättelser i Agile beskriver kraven på en produkt ur användarens synvinkel. Med andra ord berättar user stories vilka egenskaper och funktioner en produkt bör ha. Detta gör dem till ett centralt verktyg för att diskutera och validera användarnas behov och arbeta med deras implementering med en gemensam förståelse. 

Användarberättelser erbjuder ett universellt språk som teammedlemmar, intressenter och kunder förstår och talar. I praktiken innebär detta att du kan använda användarberättelser för att utveckla en förståelse för den produkt som kunden vill ha och som lämnar lite utrymme för missförstånd. 

Flera användarberättelser bildar tillsammans ett användningsfall. User Stories har sitt ursprung i Agile Software Development.

Användarberättelser beskriver krav och önskemål för ett projektresultat som ska skapas ur kundens eller användarens perspektiv. Agiles användarberättelser har denna elementära struktur:

WHO (roll), vill ha VAD (mål/önskemål) VARFÖR (mervärde)?

Låt oss titta närmare på de enskilda komponenterna i user stories:

WHO (ANVÄNDARE)

Du fyller i WER-platshållaren med din kund eller en typisk representant för din målgrupp. Hur detaljerat du beskriver WHO i User Agile Story beror på User Story i sig och på hur projektet fortskrider. Var därför tillräckligt detaljerad för att skapa en meningsfull användarberättelse.

VAD (FUNKTION)

Det är här du placerar användarens önskemål. Du kan fråga dig själv vad användaren förväntar sig eller behöver. Om din produkt fortfarande befinner sig i en tidig utvecklingsfas kan du utifrån dina erfarenheter formulera antaganden om vilka funktioner användaren förväntar sig. Om du redan har en liknande produkt på marknaden kan du också härleda de önskade funktionerna från feedbacken på denna produkt.

VARFÖR (MERVÄRDE)

Först mervärdet visar varför en funktion är viktig för användaren. VARFÖR ger dig därför en ärlig reflektion över hur väl du känner till en kunds behov. För: Att inkludera ett krav i en användarberättelse är enkelt – till exempel för att kunden uttrycker en önskan om det. Men först när du förstår varför kunden behöver det har du kontexten för att implementera kravet. Först då kan du ifrågasätta om kundens förslag/önskemål effektivt tillfredsställer deras faktiska behov – eller om det kanske finns ett smartare sätt. Låt oss titta på ett exempel: 

Kunden vill ha en regncape för cykling. Därför kan du nu inkludera kravet “regncape”. Eller så kan du fråga kunden varför han behöver en regncape. Låt oss säga att kunden svarar “För att jag inte vill bli blöt”. 

Det betyder att du inte nödvändigtvis behöver leverera en regnkappa. Du kan också leverera en cykel med integrerat tak. Det avgörande är att kundens behov eller problem löses med det – nämligen att inte bli blöt. Ju bättre du förstår “varför”, desto bättre kan du utforma din användarberättelse.

Vad är User Stories i Agile (exempel)?

Du känner nu till de enskilda komponenterna i Agile User Stories. Ett exempel på en Agile-användarberättelse kan se ut så här: 

Som KUND Jag skulle vilja ETT SÄKERT LÖSENORD***,*** SÅ ATT MINA KUNDUPPGIFTER SKYDDAS.

Här är “KUND” användaren, “ETT SÄKERT LÖSENORD” funktionen och “SÅ ATT MINA KUNDUPPGIFTER SKYDDAS” mervärdet. 

När du arbetar med användarberättelser i Scrum lägger du till acceptanskriterier för dem. Acceptanskriterier beskriver de tekniska krav som user stories måste uppfylla vid tidpunkten för acceptans. Med andra ord: Acceptanskriterier är de krav du behöver för att en user story ska skapa värde.

Betydelsen av Agile-användarberättelser i eftersläpningen kan vara mer differentierad. Eftersom: I eftersläpningar kan användarberättelser inte bara beskriva krav utan också representera en speciell hierarkityp. Det finns dessa 3 hierarkityper:

Epiker: Epics är brett definierade funktionella områden av en produkt vars konkreta omfattning fortfarande kan vara oklar.

Funktioner: Funktioner är specifika prestandaegenskaper inom ett epic.

Berättelser: Stories är tekniska Agile användarberättelser och användarberättelser inom en funktion.

Du kan implementera dessa hierarkityper inom en sprint. De skapar en konkret fördel för användaren. 

För att kunna skriva användbara användarberättelser i agil projektledning är det viktigt med detaljerade diskussioner med alla intressenter. Dessa bör ge dig en omfattande förståelse för målgruppen och den produkt som ska skapas. Utifrån detta kan du sedan till exempel härleda personas. 

Dessutom har den så kallade Kriterier för investeringför att skapa en övertygande användarberättelse:

Oberoende: En user story ska vara oberoende av andra user stories. Detta innebär att implementeringen av en story inte får förutsätta att en annan story har implementerats i förväg. Fördelen med detta är att du när som helst kan prioritera användarberättelser eller ta bort dem från eftersläpningen. 

Låt oss ta en titt på cykelexemplet igen. Låt oss säga att du bestämde dig för att installera ett litet tak över sadeln på cykeln istället för en regncape så att kunden inte blir blöt längre. Så det skulle vara en användarberättelse. Men nu inser du att för ett tak måste du först utveckla en mer stabil sadel som taket kan fästas på. Det skulle vara en annan User Story. Båda berättelserna bygger på varandra. Detta är precis vad du bör förhindra.

Naturligtvis är det ibland oundvikligt att du måste göra en användarberättelse före en annan. Men som en allmän regel bör du undvika användarberättelser för vilka du först måste implementera 20 andra användarberättelser.

Förhandlingsbart: Att skriva användarberättelser kan ibland ta ganska lång tid - men de bör därför inte vara huggna i sten efteråt. Det betyder: Produktägare Intressenter och utvecklare bör alltid diskutera och förfina en user story tillsammans. 

Värdefull: Resultatet av user stories i agil projektledning måste ha ett mervärde för kunden.

Uppskattningsvis: En övertygande användarberättelse gör det möjligt för utvecklingsteamet att uppskatta hur mycket arbete som krävs för att implementera den.

Liten: En user story bör vara så “liten” att den kan realiseras under en sprint.

Testbar: Användarberättelser i Scrum bör vara testbara. Det är det enda sättet att kontrollera om de verkligen kan implementeras i praktiken.

Om du inte är bekant med att skriva användarberättelser i Agile kan de verka som extra arbete. Men användarberättelser ger teamen ett viktigt sammanhang för deras uppgifter, vilket ytterligare förtydligar vikten av varje uppgift.

I grund och botten är det så här du drar nytta av User Stories:

Användarfokus: Användarberättelser är som en problemorienterad att-göra-lista. Ditt team kan använda dem för att hålla reda på sina uppgifter och veta exakt hur de ska uppfylla användarnas behov.

Holistiskt samarbete: Användarberättelser visar alla inblandade på ett överskådligt sätt hur det går. På så sätt kan alla dra åt samma håll och om och om igen bestämma hur användaren ska få ett särskilt högt mervärde. 

Kreativa lösningar: Skapa användarberättelser i Agile-programvaruutveckling kreativa resultat . Därför att: De får teamen att tänka kritiskt kring den bästa lösningen för slutprodukten.

Kontinuerliga framgångar: Varje User Story är en liten utmaning. Teamen kan därför fira en liten framgång efter varje story. Detta motiverar genom hela utvecklingsprocessen.

Användarberättelser är ett viktigt verktyg i arbetet med agila team. De visar om och om igen i detalj för vem man utvecklar vad och varför. Detta hjälper dig inte bara att skapa en högkvalitativ produkt som är anpassad till målgruppen, utan också att hålla teamet motiverat genom hela processen. 

För att lyckas med agilt arbete på makronivå måste hela organisationen tänka och fungera på ett agilt sätt. För att stödja dig och din organisation i detta har vi arbetat tillsammans med välkända experter för att skapa Projekt Scagile utformad. Detta visar dig i olika webbseminarier hur man hanterar en agil transformation korrekt. Utbildningen är kostnadsfri. Känn dig fri att ta en titt!

Om du vill ha några mer varierade frågor för dina retrospektiv kan du läsa vårt inlägg om 32 nya retrospektiva metoder för nybörjare och proffs (med bland annat Mario Kart Retro, Marathon Retro och Elon Musk Retro).

En av de bästa metoderna för att hållbart utveckla teammedlemmarnas agila tankesätt är förresten att implementera en agil hälsokontroll. Vår gratis Team-Health Check byggsats kan hjälpa dig att ställa rätt frågor - klicka dig bara igenom.