Hvad er brugerhistorier?

Formålet med en User Story er at forklare, hvordan nogle funktioner vil give værdi til en bestemt type kunde.

Brugerhistorier er en kort beskrivelse af et produkt skrevet fra slutbrugerens perspektiv. Det kan omfatte nogle af følgende: funktioner, funktionalitet, fejlrettelser, forbedringsanmodninger, infrastrukturopsætning eller teknisk dokumentation. Formålet med en brugerhistorie er at forklare, hvordan en funktion vil give værdi for kunden.

Et af nøgleelementerne i Agile-tilgangen er at sætte mennesker først, og en brugerhistorie sætter slutbrugeren i centrum for planlægningen og udførelsen af et produkt. Disse historier er uformelle og ikke-tekniske for at give udviklingsteamet en kontekst fra det virkelige liv. At læse brugerhistorier bør give teamet en bedre forståelse af det produkt, de er ved at bygge, og den værdi, det skaber for brugeren. 

Overordnet hjælper brugerhistorier teamet med at fastholde et brugerfokus på deres daglige arbejde, hvilket igen driver samarbejde, kreativitet og et bedre samlet produkt.

Hvem er ansvarlig for brugerhistorier?

Der er ikke én enkelt person eller rolle i Agile-teamet, der er ansvarlig for brugerhistorier. Faktisk kan alle involverede i projektet skrive brugerhistorier fra teammedlemmerne lige igennem til interessenterne. Der bliver dog skrevet mange historier i løbet af en raffinering af efterslæb eller sprint planlægning møde af udviklingsteamet og Product Owner. 

Det er også værd at bemærke, at hvem der skriver brugerhistorien er langt mindre vigtig, end hvem der er involveret i diskussionerne om den.

Hvordan man skriver brugerhistorier

Følgende er nyttigt at overveje, når du skriver brugerhistorier: 

Definition of Done:
Det er vigtigt at have en klar forståelse af, hvad der skal til, for at brugerhistorien er færdig. Historien kan betragtes som "færdig", når slutbrugeren kan fuldføre den skitserede opgave (ofte omtalt som tilfredshedskriterier), og når den opfylder aftalte standarder (Definition of Done).  

Feedback:
Samarbejde med brugere for at fange problemet eller behovet med deres ord. Der er ingen værdi i at gætte, hvad de vil.

Brug bestilte trin:
Skriv en historie for hvert trin i den større proces eller mål. 

Bruger personas:
En fælles forståelse blandt teamet af, hvem slutbrugeren er og deres specifikke behov.

Flyde:
Hvis en historie sandsynligvis vil tage længere tid end varigheden af en Sprint, bør den opdeles i mindre historier eller betragtes som sin egen 'Epic'. Estimering af brugerhistorier er nyttigt, når man skal vurdere, om historier skal deles yderligere op for at sikre et godt flow i arbejdet. 

Når først brugerhistorierne er klart defineret, er det vigtigt at sikre, at de er synlige for hele teamet.

Brugerhistories skabelon og eksempler

Brugerhistorier er ofte skrevet på kartotekskort, sticky notes, eller hvis teams vælger en digital version, online software. En ofte brugt skabelonskabelon omfatter følgende: 

Som [type bruger] ønsker jeg [en eller anden funktion], så [en eller anden værdi].

Lad os nedbryde dette yderligere: 

  • [Type af bruger]: Det er præcis, hvem der bruger produktet og deres persona. Teamet skal have en fælles forståelse af, hvem de er og deres krav. 
  • [Nogle mål]: Her beskrives hensigten i stedet for en specifik funktion, de ønsker at bruge. 
  • [En eller anden grund]: Endelig er dette grunden til, at de forsøger at opnå dette. Dvs. Hvad er den samlede fordel, de forsøger at opnå? Hvad er det større problem, der skal løses?

For eksempel kan brugerhistorier i praksis se sådan ud: 

  • Som [bruger] vil jeg [specificere mapper, der skal sikkerhedskopieres], så [mit drev ikke er sikkerhedskopieret med mapper, jeg ikke har brug for]. 
  • Som [bruger] vil jeg [organisere mit virtuelle arbejdsområde], så [jeg kan føle mere kontrol over mit arbejde]. 
  • Som [leder] ønsker jeg at [være i stand til at forstå holdets fremskridt], så [jeg kan rapportere om succes og fiaskoer med lethed]. 

De behøver ikke altid at følge denne struktur, men dette kan være nyttigt til at definere kriterierne for tilfredshed og definitionen af "Udført". 

[Du kan læse mere om Definition of Done i vores andre ressourcer her]

Hvorfor oprette brugerhistorier?

Vi har undersøgt, hvad brugerhistorier er, og hvordan man opretter dem, men det er også vigtigt at forstå, hvorfor oprettelse af brugerhistorier giver reel værdi for teams. Nogle gange for udviklingsteams, der er nye til Agile, kan brugerhistorier virke som et ekstra og unødvendigt skridt. Men historier giver teamet brugbar kontekst og forbinder opgaver med den værdi, disse opgaver bringer. 

Nogle af de vigtigste fordele ved brugerhistorier inkluderer: 

  • Historier driver samarbejde. At have et klart defineret slutmål kan sætte teamet i stand til at arbejde sammen om, hvordan man bedst tjener slutbrugeren og når dette mål. 
  • Historier hjælper med at definere roller. På grund af historiernes kortfattede og brugerfokuserede karakter kan det være lettere at adskille, hvem der beskæftiger sig med hvad, og definere roller.
  • Historier skaber fremdrift. På grund af at være små arbejdsenheder, kan teamet fejre regelmæssige sejre, hvilket er med til at skabe og fastholde momentum. 
  • Historier tilskynder til kreativ tænkning. Historier er med til at drive teamet til at tænke kreativt over, hvordan man bedst løser et slutmål.

Resumé

Sammenfattende er det klart, at brugerhistorier giver nogle betydeligt væsentlige fordele. At sætte slutbrugeren i centrum for arbejdet og samtalen skaber værdi ved at hjælpe teams med at bygge et succesfuldt produkt og motivere dem til at gøre det undervejs. At komme overens med historier og bruge dem effektivt er derfor vigtigt for teams, der bruger Agile.

Del:

Relateret blogindlæg

10 fordele ved at bruge Sprint Goals.

Hos Better Change tror vi på, at teamsamarbejde kan skabe værdi i organisationer. Et vigtigt og ofte overset aspekt af dette er brugen af Sprint Goal'er. Det er klare, præcise mål for hver Sprint, som giver Scrum-teams retning og fokus.

Misforståelser i softwarespecifikationer.

Der er ofte misforståelser i softwarespecifikationsdokumenter. Den løsning, vi typisk vælger, er at lave mere detaljerede specifikationer. Men det fører desværre ikke til bedre resultater.

Relateret uddannelse

Relaterede ressourcer

Sådan kører du en Retrospective.

At køre et effektivt retrospektiv er afgørende for løbende forbedringer i Agile-teams. Hvis du nogensinde har følt, at dit teams retrospektiver mangler retning eller ikke producerer handlingsrettede indsigter, er du...

Scrum-processen forklaret

Få indblik i Scrum-processens finesser, og lær, hvordan dette agile-framework kan revolutionere projektledelse.

Flere ressourcer

Lad os snakke om
Hvordan vi kan hjælpe!

Nyder du vores artikler? Endnu bedre er det, hvis du kan tale med os personligt! Kontakt os, så vi kan planlægge noget!