Scrum Guide | 19. Brugerhistorier – hvad er de?

Brugerhistorie er en kort beskrivelse af en ny produktfunktionalitet eller dens forbedring. Den indeholder ikke en teknisk løsning, men adresserer spørgsmål vedrørende funktionaliteten: Hvem er brugeren? Hvad gør produktet? Og hvad er dets formål? Brugerhistorien beskriver produktet i hverdagssprog eller forretningssprog, selvom den også peger på Scrum-teamets opgaver, der har til formål at forbedre teamets præstation.

Hvad er brugerhistorier? – indholdsfortegnelse:

1. Introduktion
2. Brugerhistorie. Hvis historie er det?
3. Hvordan bruger man brugerhistorier?
4. Acceptkriterier
5. Sammenfatning

Introduktion

Brugerhistorie er den mest almindelige måden at formulere opgaverne udført af Scrum-teamet. En enkelt brugerhistorie definerer en lille funktionalitet af produktet. Den beskriver det mindste meningsfulde, delvise produktmål. Af denne grund er brugerhistorier meget korte.

Brugerhistorier oprettes gennem hele arbejdet med produktet. De oprettes kontinuerligt, fra det øjeblik beslutningen om at påbegynde arbejdet træffes, til realiseringen af produktmålet.

At oprette brugerhistorier er en produktansvarliges opgave. Baseret på en samtale med en kunde formulerer de svar på spørgsmål, der gør det muligt at oprette en brugerhistorie og indtaster dem i produktbackloggen. Dog afspejler brugerhistorier ikke kun kundens behov.

Brugerhistorie. Hvis historie er det?

Scrum-teamet opretter en brugerhistorie for at definere brugerens behov, og derfor er den skrevet i forretningssprog. Med andre ord angiver den de fordele, som implementeringen vil bringe til produktbrugeren. Dog kan der i produktbackloggen også være brugerhistorier, der beskriver udviklingsteamets behov, for eksempel forbedring af arbejdsgangen mellem udviklere, eller beskriver produktansvarliges behov, for eksempel organisering af produktbackloggen. I sådanne tilfælde er brugeren i brugerhistorien udvikleren og produktansvarlig.

Du kan beskrive en brugerhistorie ved at besvare 3W spørgsmålene:

• Hvem?
• Gør hvad?
• Hvorfor?

Brugerhistorien er derefter indeholdt i en formel:

Som en [brugertype], jeg vil [gøre hvad?] Fordi [hvorfor?].

Eksempler på brugerhistorier om funktionaliteten af en online butik skrevet i denne form er illustreret i tabellen nedenfor:

Denne formel gør det muligt ikke kun at formulere en brugerhistorie, men også relativt let at oversætte teknisk sprog til forretningssprog og omvendt. Som et resultat ser både udviklere og interessenter klart målet og faserne af dets fremskridt. Vi vil også dække oprettelsen af gode brugerhistorier ved hjælp af INVEST-metoden i en separat artikel i Scrum Guide-serien.

Hvordan bruger man brugerhistorier?

At oprette en skematisk brugerhistorie er kun begyndelsen. De er signaler og udgangspunkt for diskussioner om problemer og deres løsninger. Diskussionen af brugerhistorier finder sted under sprintplanlægning for at afklare, hvilke tekniske problemer udviklingsteamet vil tilføje til sprintbackloggen.

Typisk er brugerhistorier i det fysiske rum skrevet på små, farvede kort fastgjort i arbejdsområdet. Dog fungerer digitale whiteboards, delt af Scrum-teamet, bedst i det digitale rum.

At gemme brugerhistorier på denne måde har flere fordele, fordi:

• Understreger autonomien af hver brugerhistorie – hver har en separat ramme og kan udføres uafhængigt af de andre
• Fremhæver dynamikken i brugerhistorier – rækkefølgen af deres realisering genforhandles af Scrum-teamet, og den aktuelle rækkefølge af realisering er synlig på tavlen takket være den fysiske placering af kortene med brugerhistorier
• Tjener som en påmindelse – takket være den visuelle repræsentation af brugerhistorier har Scrum-teamet et vejskilt i sigte for at minde dem om målet, når de skaber detaljerede løsninger.

Udviklingsteamet estimerer den nødvendige indsats for at fuldføre en brugerhistorie i dage, mandetimer eller story points.

Acceptkriterier

En brugerhistorie skal have bestemte acceptkriterier i det øjeblik, den accepteres til udvikling af udviklingsteamet. Acceptkriterierne bestemmer, hvornår arbejdet på en brugerhistorie kan betragtes som færdigt.

På denne måde ved både klienten og udviklerne, hvordan deres arbejde vil oversættes til forretningsværdi. Typisk betragtes en brugerhistorie som færdig, når brugeren angivet i den kan udføre den beskrevne handling. Ved at bruge eksemplet ovenfor, se på denne brugerhistorie med indholdet:

En kunde kan købe en tryllestav med et enkelt klik.

Den er færdig, når en fungerende “Køb nu”-knap vises på online butikssiden, som bruger de standard betalings- og forsendelsesoplysninger for den indloggede bruger.

Sammenfatning

En brugerhistorie er en kortfattet beskrivelse af en ny produktfunktionalitet eller forbedring. Den fungerer som det mindste mål udtrykt i forretningssprog, det vil sige, fra perspektivet af forretningsværdi og brugeren. Den hjælper med klart at definere den opgave, der skal udføres, samt kriterierne for dens fuldførelse.

Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.