I mjukvaruutveckling är en användarberättelse en mening som beskriver en enda funktion eller delfunktion som användaren behöver kunna göra med produkten - exemplevis som en viktig del av en arbetsuppgift. Den beskriver kort och koncist: vad, för vem och varför funktionen behövs. Det skrivs ofta ner på ett A5-kort med penna och papper - varför gör det mer komplicerat än så?  

Jag ska visa vad jag menar.

Om man googlar "användarberättelse" eller "user story" som det heter på engelska, hittar man en mall som ser ut så här:

"Som en <person> vill jag <funktion> för att <behov>".

Genom att fånga alla behov i en bunt användarberättelser så kan ett företag enkelt samla, sortera och prioritera vad de borde göra. Men själv tycker jag att det här är bak och fram.  

Från stressad chef till inspirerande ledare!

Känner du dig överväldigad i din ledarroll? I så fall är du inte ensam. Med onlineutbildningen Leda mig själv, går du från stress och reaktivitet till självledarskap, fokus och starka teamresultat.

Kolla in vårt specialerbjudande på denna kraftfulla 1-timmesutbildning.

Transformera ditt ledarskap nu!

Känner du dig ibland otillräcklig, reaktiv och stressad i din chefsroll?

Upptäck "Leda mig själv" och stärk dig själv i ditt ledarskap:

• Från stress till kontroll
• Från händelsestyrd vardag till proaktiv styrning mot mål
• Från missförstånd och konflikter till engagemang och positiv teamdynamik

Nu kan du köpa onlineutbildningen ”Leda mig själv” till rabatterat pris och samtidigt få ett årsmedlemskap på Motivation.se.

Paketerbjudande: 995 kr – spara över 1.600 kr!

Vässa ditt ledarskap idag!

Man ska börja med varför.

En användarberättelse som börjar med varför skulle se ut så här istället:

"För att <behov> som en <person> vill jag <funktion>".

En ganska trivial förändring och du undrar säkert varför det här skulle vara så viktigt?  Jo, det är så här - om du sätter <funktion> före <behov> så tänker du utifrån vad du vill ha och glömmer oftast bort varför du vill ha det.  Jag har sett för många användarberättelser där behovet har blivit en efterhandskonstruktion och har en tendens att se ut så här: "För att det blir bättre så…". Knappast något användbart.  

Genom att sätta <behov> före <funktion> sätter man kundens (eller sin egen) fokus på värdet i det man försöker uppnå. 

Behovet först

Vi tar ett enkelt exempel. I det klassiska formatet så har vi en möjlig story:

Som en läsare av Motivation.se

Vill jag kunna välja ut de områden som jag tycker är intressanta och bara dem när jag surfar in på www.motivation.se

För att jag ska slippa se saker som är ointressanta för mig

Och vi vänder på det:

För att jag ska slippa se saker som är ointressanta

Som en  läsare av Motivation.se

Vill jag kunna välja ut de områden som jag tycker är intressanta och bara se dem när jag surfar in på www.motivation.se

Det första som händer är att vi genast börja tänka kring behovet - är det verkligen den motiverande faktor för den här användarberättelsen? Handlar det egentligen mer om att våra läsare har mycket att göra och inte vill att det ska ta flera minuter att kolla om det finns nya relevanta artiklar? Om det är där skon klämmer så kanske det snarare ska se ut så här:

För att snabbare kunna komma till det material som jag vill läsa

Som en läsare av Motivation.se

Vill jag kunna välja ut de områden som jag tycker är intressanta och se bara dem när jag surfar in på www.motivation.se

Fördelarna

Men det är mer än så, det finns många fördelar med att sätta fokus på varför:

• Det blir mer tydligt om behovet uppfylldes - bara för att du skapade <funktion> behöver inte det betyda att du löste <behovet>. Med <funktion> först så kommer du utvärdera projektet utifrån frågan "Lyckades vi implementera <funktionen>?"  istället för det som är mycket mer kritiskt "Lyckades vi uppfylla <behovet>?" 
• Under projektets gång kommer de som jobbar med <funktion> komma på frågor och funderingar. Med fokus på <behov> så finns det en större chans att de kan lösa problemet utan att behöva gå tillbaka till kunden. 
• Andra människor än den som skrev storyn kanske känner till ett bättre sätt att lösa <behovet> - men om fokus har varit på vad istället för varför så är sannolikheten betydligt mindre. Det händer förvånansvärt ofta att någon ser användarberättelsen med en bra beskrivning av <behovet> och utbrister:  "Men det där  kan vi uppfylla med det här som vi redan har!"
• En liten praktisk detalj: det blir mycket lättare att få en överblick och prioritera bland alla användarberättelser om det första du ser på varje kort är behovet. Du behöver inte leta - en detalj som blir viktig när man har hundratals användarberättelser att prioritera.
• För någon utomstående som inte förstår projektet eller produkten så blir en användarberättelse som börjar med ett <behov> betydligt enklare att förstå. När man läser <behovet> först ställs hjärnan in på kontexten och då blir <funktionen> automatiskt lättare att förstå. Att kunna diskutera användarberättelserna och få hjälp från utomstående kan vara viktigt för projektet.
• Sannolikheten att du hittar synergier i alla användarberättelser blir större om du lägger fokus på <behovet>.  Det är mycket möjligt att <behov 1> och <behov 2> faktiskt uppnås med <funktion 3> istället för två helt separata <funktioner>.   
• Och sist men inte minst:  med <behovet> först leder tankarna till det faktiska affärsvärdet i det du försöker göra. Börja med att tänka på varför skulle det här vara så viktigt egentligen? Vad kommer kunden vinna på om vi gör det här?  Hur mycket är kunden beredd att betala för det?

Real world example

Öka fokus med hjälp av en tomat. Snabbkurs i Pomodoro-metoden.

Jag vill avrunda med att titta på en real world example som dök upp på jobbet nyligen:

Som vikarie 

Vill jag kunna registrera närvaro/frånvaro i systemet 

För att det ska göras så fort som möjligt under skoldagen

Jag hoppas att jag har valt ut ett område som är lätt för de flesta läsare att förstå. Det handlar om att rapportera närvaro eller frånvaro på skolbarn när de sitter i klassen. I systemet i fråga så har läraren rätt att göra det, men om läraren skulle vara sjuk så kan vikarien inte rapportera i dagsläget.

Här ser vi ett klassiskt fall av att <behovet>kommer som en eftertanke.  "För att det ska göras så fort som möjligt under skoldagen" - visst låter det okej som <behov>? Men här ser man ett klassiskt misstag - man beskriver <behovet> utifrån <funktionen>  - vi använder ordet "det" istället för att förklara vad vi faktiskt menar.  

För att visa tydligare vad jag menar, prova att ändra ordningen utan att skriva om:

För att det ska göras så fort som möjligt under skoldagen

Som vikarie 

Vill jag kunna registrera närvaro/frånvaro i systemet 

Så ser man att det inte är lätt att förstå behovet utan att läsa hela storyn. Vi kan göra bättre, och genom att försöka skriva <behovet> först så händer det något magiskt - <behovet> blir bättre formulerat. Istället kan vi komma fram till en bättre användarberättelse:

För att vårdnadshavare ska kunna veta så fort som möjligt om deras barn saknas i skolan 

Som en vikarie

Vill jag kunna registrera närvaro / frånvaro för alla elever i början av klassen

Vi ser direkt att anledning är egentligen inte bara att det ska ske "så fort som möjligt" - utan att det egentligen handlar om att föräldrar till barn som saknas på en lektion ska veta om det på en gång. För tänk om något hänt barnet som inte dykt upp i skolan?

Användarberättelsen går från att handla om att göra något effektivt till att faktiskt handla om barns säkerhet. Prioriteringen blir tydligare - är barnens säkerhet viktigt för oss? Självklart!

Så mitt råd är enkelt. Börja med varför så kommer du få en bättre resultat.