User stories

Er en kort simpel beskrivelse af en feature, som en potentiel bruger ville formulere det. Typisk en bruger eller en kunde.

En user story can uformelt skrives som: Tilmeldte brugere kan nulstille deres kodeord.

En lidt mere formel udgave kunne være:

• Som en tilmeldt bruger
• Ønsker jeg at kunne nulstille mig kodeord
• Så jeg kan logge på systemet hvis jeg har glemt mit kodeord

Formatet følger altså denne form:

• Som hvem,
• Ønsker jeg hvad,
• Så jeg hvorfor.

Formålet med acceptkriterier er at kunne afgøre, om vores user stories fungerer efter hensigten. Altså at bringe vores opmærksomhed fra at systemet “fungerer som programmøren har lavet det” til “fungerer sådan som den oprindelige intention bag en user story har været”. “It works as coded” til “It works as intented”.

Det er typisk de krav som systemet skal leve op til før en kunde vil kunne godkende det.

Følgende format kan f.eks. anvendes:

• Givet en forudsætning,
• Når jeg foretager mig noget,
• Så forventer jeg resultatet.

På engelsk: Given, When, Then

Det er et format, som er let at teste. Enten lever systemet op til acceptkriteriet, eller også fejler det.

Eksempel:

User Story: Som en tilmeldt bruger, ønsker jeg at kunne nulstille mit kodeord, sådan at jeg kan logge på systemet igen, når jeg har glemt mig kodeord.

Accept-kriterium: Givet at jeg er tilmeldt systemet som bruger. Når jeg klikker på et “jeg har glemt mit kodeord” link, så modtager jeg en mail med et link til at nulstille kodeordet og når jeg klikker på linket kan jeg indtaste et nyt kodeord, for bagefter at kunne logge på.

Udviklerne og kunden (product owner) sidder som regel sammen og kører alle accept-kriterierne igennem inden systemet kan godkendes som leveret.

Use Cases er som et detaljeret kort over, hvordan en bruger interagerer med et system for at nå et mål — med hovedforløb, alternative veje, fejlscenarier osv. User Stories er korte beskrivelser af, hvad en bruger vil opnå og hvorfor — tænkt til hurtig planlægning og dialog i et agilt team.

User Stories opstod, fordi udvikling bevægede sig mod agile metoder, hvor man ønskede:

• Mindre dokumentation
• Hurtigere tilpasning
• Små leverancer
• Fokus på værdi for brugeren

Use Cases kan være tunge og detaljerede og bruges typisk tidligere i designet, mens User Stories er lettere, uformelle og fleksible.

User Stories lå derfor godt i tråd med agile arbejdsformer som Scrum og XP, som havde brug for en hurtig, samtalebaseret måde at arbejde med krav på.

Her er en kort tidslinje for udviklingen af Use Cases → User Stories (inkl. centrale milepæle og oprindelse). Kilder er angivet efter afsnit.

• Ivar Jacobson introducerer idéen om use cases hos Ericsson som teknik til at beskrive funktionelle krav.

• Jacobson udgiver “Object-Oriented Software Engineering: A Use Case Driven Approach”
• Gør use cases populære som central analysemetode i OO-udvikling.

• Jacobson slår sig sammen med Grady Booch og James Rumbaugh (“The Three Amigos”).
• UML (Unified Modeling Language) udvikles og standardiserer Use Case Diagrams.

👉 Use cases kom altså før UML, men UML gjorde dem til en officiel del af notationen.

• I Extreme Programming (XP) introduceres User Stories som et lettere alternativ til tunge kravdokumenter.
• De bruges som små, fleksible kravkort, skrevet i dialog mellem udviklere og kunder.

• User Stories vinder bredt indpas sammen med agil udvikling.
• Bevæger sig væk fra tung dokumentation → fokus på samtale og hurtig feedback.

• Use Cases anvendes stadig, især i større projekter og domæneanalyse.
• User Stories bruges typisk i Scrum, XP og Kanban til løbende planlægning.
• Mange teams kombinerer metoderne (fx User Stories → detaljeres i Use Cases ved behov).