Scrum User Story

User Stories

Definition

En User Story er et udtryk for et bruger behov

Som en <Persona>
Ønsker Jeg <Behov>
Således at jeg kan <et resultat, noget nyt>

Personas
Når projektet kræver det – f.eks. når brugeroplevelse er en væsentlig faktor i løsningen – udformer teamet detaljerede, kunstige biografier fra fiktive brugere af den fremtidige løsning: disse kaldes ‘Personas’ (skab eventuelt falske burgere og design til dem)

Personas er kortfattede og visuelle; De laves ofte som fysiske kort og er en enkelt side med et billede, et navn og sociale eller professionelle detaljer: “Henriette Sørensen, 34, pressechef i en stor detailvirksomhed, osv.”

Et softwareprodukt skal generelt bruges af mere end én kategori af personer, med forskellige præferencer og forventninger til produktet – på samme måde skaber teamet én persona for hver kategori de anser som værende vigtig for brugeroplevelsen og designet.

Udarbejdelsen af User Stories

I samarbejde med kunden eller Product Owner inddeles produktet/løsningen i funktionelle inddelinger, der kaldes User Story.

Når hver User Story er leveret forventes det, at den bidrager til værdien af det overordnede produkt, uanset hvornår den implementeres. Kriterierne for at lave en god User Story fremgår af INVEST formlen.

INVEST
Akronymet INVEST er en hjælpende hånd til at huske et bredt accepteret sæt af kriterier, eller en tjekliste, der vurderer kvaliteten af en User Story. Hvis User Story ikke lever op til et af disse kriterier, bør teamet omformulere det eller endda overveje at lave det helt om (hvilket ofte betyder, at man fysisk ødelægger de gamle ’story cards’ og skriver nogle nye).

En god User Story bør være:
• Independent (uafhængig af alle andre User Stories)
• Negotiable (omsættelig – omfatter ikke en specifik kontrakt)
• Valuable (værdifuld for brugeren)
• Estimable (Kan estimeres i form af indsats)
• Small (lille så den kan passe ind i et Sprint/Iteration)
• Testable (mulig at teste i princippet, også selvom der endnu ikke findes en test for dette område)

Opdeling af User Stories
Inden en User Story er klar til et sprint (US Ready) bør den være ”lille nok”. En tommelfingerregel er , at en User Story bør kunne gennemføres inden for et SPRINT men selv her er det en stor størrelse. Derfor er vores anbefaling at en User Story bør nedbrydes yderligere indtil den kan løses på 2-3 arbejdsdage.

En yderligere opdeling af User Storyen i mindre dele medfører også at disse skal evalueres for deres værdi til den samlede løsning.

Andre typer af “Stories”

Af andre typer af stories skal vi her nævne “Enabler stories”. Disse omfatter rene tekniske aspekter som f.eks. at bygge integrationer, interfaces m.m. Disse stories vil  ikke være en del af de funktionelle user stories som er placeret på brugerfladen.

En anden form for User Stories vi har brugt i vores træning- og implementeringssarbejde er “Analyse User Stories”. Denne type er typisk et stykke analyse arbejde, der har til hensigt at modne(grooming) den egentlige user story med henblik på identifikation af teknisk løsning eller fastlæggelse af mere detaljerede krav fra brugerne.

Hvorfor har vi anbefalet disse typer ?
Ethvert Sprint skal fyldes med Stories som der kan beregnes en indsats efter. Denne rbuges til opgørelse af hvad teamet tror de kan nå. Ved at anvende andre typer af Stories kan teamet få et bedre planlægnings- og koordineringsgrundlag for gennemførelsen af selve sprintet.