Brugerhistorier i Scrum: Alt hvad du behøver at vide

Målet er klart: Du ønsker at udvikle et produkt, der giver kunderne en høj merværdi. Man ønsker at opnå et resultat, som teammedlemmer og interessenter er tilfredse med. Men hvordan opnår man dette mål? Hvordan kan man opfylde alle kravene til et produkt i små, grundige trin? 

I Agile har brugerhistorier vist sig at være et effektivt værktøj til dette. De tager dig trin for trin fra den første idé til et produkt, der er klar til salg. Jeg vil vise dig, hvad brugerhistorier er, hvordan du opretter dem, og hvordan du kan drage fordel af dem.

Definitionen af user stories i Agile beskriver kravene til et produkt set fra brugerens synsvinkel. Med andre ord fortæller user stories, hvilke egenskaber og funktioner et produkt skal have. Det gør dem til et centralt værktøj til at diskutere og validere brugernes behov og arbejde på deres implementering med en fælles forståelse. 

Brugerhistorier giver et universelt sprog, som teammedlemmer, interessenter og kunder forstår og taler. I praksis betyder det, at du kan bruge brugerhistorier til at udvikle en forståelse af det produkt, som kunden ønsker, der ikke levner meget plads til misforståelser. 

Flere user stories danner tilsammen en use case. Brugerhistorier har deres oprindelse i Agile Software Development.

Brugerhistorier beskriver krav og ønsker til et projektresultat, der skal skabes ud fra kundens eller brugerens perspektiv. Agile brugerhistorier har denne elementære struktur:

WHO (rolle), ønsker HVAD (mål/ønske) HVORFOR (merværdi)?

Lad os se nærmere på de enkelte komponenter i user stories:

HVEM (BRUGER)

Du udfylder WER-pladsholderen med din kunde eller en typisk repræsentant for din målgruppe. Hvor detaljeret du beskriver WHO i User Agile Story, afhænger af selve User Story og af projektets fremdrift. Vær derfor detaljeret nok til at skabe en meningsfuld brugerhistorie.

HVAD (FUNKTION)

Det er her, du placerer brugerens ønsker. Du kan spørge dig selv, hvad brugeren forventer eller har brug for. Hvis dit produkt stadig er i en tidlig udviklingsfase, kan du ud fra dine erfaringer formulere antagelser om, hvilke funktioner brugeren forventer. Hvis du allerede har et lignende produkt på markedet, kan du også udlede de ønskede funktioner fra feedbacken på dette produkt.

HVORFOR (MERVÆRDI)

Først når merværdien er tydelig, forstår brugeren, hvorfor en funktion er vigtig. HVORFOR giver dig derfor mulighed for ærligt at reflektere over, hvor godt du kender kundens behov. For: Det er nemt at inkludere et behov i en brugerhistorie – for eksempel fordi kunden udtrykker et ønske om det. Men først når du forstår, hvorfor kunden har brug for det, har du konteksten for implementeringen af behovet. Først da kan du sætte spørgsmålstegn ved, om kundens forslag/ønske effektivt opfylder deres egentlige behov – eller om der muligvis er en smartere måde. Lad os se på et eksempel: 

Kunden ønsker sig en regnkappe til cykling. Derfor kan du nu inkludere kravet “regnkappe”. Eller du kan spørge kunden, hvorfor han har brug for en regnkappe. Lad os sige, at kunden svarer “Fordi jeg ikke vil blive våd”. 

Det betyder, at du ikke nødvendigvis behøver at levere en regnfrakke. Du kan også levere en cykel med integreret tag. Det afgørende er, at kundens behov eller problem løses – nemlig at undgå at blive våd. Jo bedre du forstår “hvorfor”, jo bedre kan du designe din brugerhistorie.

Hvad er brugerhistorier i Agile (eksempel)?

Du kender nu de enkelte komponenter i Agile-brugerhistorier. Et eksempel på en Agile-brugerhistorie kan se sådan ud: 

Som KUNDE Jeg vil gerne EN SIKKER ADGANGSKODE***,*** SÅ MINE KUNDEDATA ER BESKYTTET.

Her er den “KUNDEN” brugeren, “EN SIKKER ADGANGSKODE” funktionen og “SÅ MINE KUNDEDATA ER BESKYTTET” merværdien. 

Når man arbejder med user stories i Scrum, tilføjer man acceptkriterier til dem. Acceptkriterier beskriver de tekniske krav, som user stories skal opfylde på accepttidspunktet. Med andre ord: Acceptkriterier er de krav, du har brug for, for at en user story kan skabe værdi.

Betydningen af Agile-brugerhistorier i backloggen kan være mere differentieret. Fordi: I backlogs kan brugerhistorier ikke kun beskrive krav, men også repræsentere en særlig hierarkitype. Der er disse 3 hierarkityper:

Epos: Epics er bredt definerede funktionelle områder af et produkt, hvis konkrete omfang stadig kan være uklart.

Funktioner: Features er specifikke præstationsegenskaber i et epos.

Historier: Historier er tekniske Agile brugerhistorier og brugerhistorier inden for en funktion.

Du kan implementere disse hierarkityper inden for et sprint. De skaber en konkret fordel for brugeren. 

For at kunne skrive brugbare user stories i agil projektledelse er det afgørende med detaljerede diskussioner med alle interessenter. De skal give dig en omfattende forståelse af målgruppen og det produkt, der skal skabes. Ud fra dette kan du så udlede f.eks. personas. 

Derudover er den såkaldte INVEST-kriteriertil at skabe en overbevisende brugerhistorie:

Uafhængig: En user story skal være uafhængig af andre user stories. Det betyder, at implementeringen af en story ikke må forudsætte, at en anden story er blevet implementeret forinden. Det har den fordel, at man til enhver tid kan prioritere brugerhistorier eller fjerne dem fra backloggen. 

Lad os tage endnu et kig på cykeleksemplet. Lad os sige, at du besluttede dig for at installere et lille tag over cyklens sadel i stedet for en regnkappe, så kunden ikke længere bliver våd. Så det ville være en brugerhistorie. Men nu indser du, at du først skal udvikle en mere stabil sadel, som taget kan fastgøres til, for at få et tag. Det ville være en anden User Story. Begge historier bygger på hinanden. Det er præcis det, du skal forhindre.

Selvfølgelig er det nogle gange uundgåeligt, at du er nødt til at lave en user story før en anden. Men som en generel regel skal du undgå user stories, hvor du først skal implementere 20 andre user stories.

Kan forhandles: Det kan nogle gange tage lang tid at skrive brugerhistorier - men de bør derfor ikke være hugget i sten bagefter. Det betyder: Product Owner Interessenter og udviklere bør altid diskutere og finpudse en user story sammen. 

Værdifuld: Resultatet af brugerhistorier i agil projektledelse skal have merværdi for kunden.

Anslået: En overbevisende brugerhistorie gør det muligt for udviklingsteamet at estimere, hvor stor en indsats det vil kræve at implementere den.

Lille: En user story skal være så “lille”, at den kan realiseres i et sprint.

Kan testes: Brugerhistorier i Scrum skal kunne testes. Det er den eneste måde at kontrollere, om de virkelig kan implementeres i praksis.

Hvis du ikke er bekendt med at skrive brugerhistorier i Agile, kan de virke som ekstra arbejde for dig. Men brugerhistorier giver teams en vigtig kontekst for deres opgaver, hvilket yderligere tydeliggør vigtigheden af hver opgave.

Dybest set er det sådan, du får gavn af User Stories:

Fokus på brugeren: Brugerhistorier er som en problemorienteret to-do-liste. Dit team kan bruge dem til at holde styr på deres opgaver og vide præcis, hvordan de skal opfylde brugernes behov.

Holistisk samarbejde: Brugerhistorier viser alle involverede på et øjeblik, hvor tingene bevæger sig hen. På den måde kan alle trække på samme hammel og beslutte igen og igen, hvordan brugeren får en særlig høj merværdi. 

Kreative løsninger: Opret brugerhistorier i Agile-softwareudvikling kreative resultater . Fordi: De får teams til at tænke kritisk over den bedste løsning for det endelige produkt.

Konsekvente succeser: Hver User Story er en lille udfordring. Teams kan derfor fejre en lille succes efter hver historie. Det motiverer gennem hele udviklingsprocessen.

Brugerhistorier er et vigtigt værktøj i agile teams arbejde. De viser dig igen og igen i detaljer, for hvem du udvikler hvad og hvorfor. Det hjælper dig ikke kun med at skabe et produkt af høj kvalitet, der er skræddersyet til målgruppen, men også med at holde teamet motiveret gennem hele processen. 

For at du kan få succes på dette makroniveau af agilt arbejde, skal din organisation som helhed tænke og fungere agilt. For at støtte dig og din organisation i dette, har vi arbejdet sammen med anerkendte eksperter for at skabe Projekt Scagile designet. Det viser dig i forskellige webinarer, hvordan du griber en agil transformation korrekt an. Træningen er gratis. Du er velkommen til at tage et kig!

Hvis du gerne vil have nogle mere varierede spørgsmål til dine retrospektiver, kan du læse vores indlæg om 32 friske retrospektive metoder til begyndere og professionelle (med bl.a. Mario Kart Retro, Marathon Retro og Elon Musk Retro).

En af de bedste metoder til bæredygtigt at udvikle teammedlemmers agile mindset er i øvrigt implementeringen af et agilt helbredstjek. Vores gratis Team-Health Check-byggesæt kan hjælpe dig med at stille de rigtige spørgsmål - klik dig bare igennem.