User stories cheatsheet

Som bruger vil jeg kunne gemme opskrifter som favoritter, så jeg hurtigt kan finde dem igen.

Fin, lille story.

AC beskriver både at gemme, finde og fjerne en favorit.

Som studerende vil jeg kunne oprette en køretur, så andre studerende kan se, om de kan køre med.

Fin story med tydelig bruger og værdi.

AC gør funktionen konkret.

Mulig diskussion: Er “Det skal være muligt at se, hvor mange ledige pladser der er” et acceptkriterium? Ja, hvis det er en del af det, vi har besluttet, at denne story skal levere. Her skal man passe på scope creep. Vær tydelig omkring hvad der er indenfor og udenfor scope.

Som bruger vil jeg gerne have en god oplevelse, så jeg bliver glad.

Problemer:

• “God oplevelse” er meget uklart.
• “Bliver glad” er ikke et konkret brugerbehov.
• AC’erne er meget vage.
• Hvordan afgør vi, om storyen er færdig?

Den kan måske pege på et ret svagt formuleret non-funktionelt krav om brugervenlighed, men den er ikke en god funktionel user story.

Som bruger vil jeg kunne registrere min træning, så jeg kan følge min udvikling over tid.

Fin story.

AC’erne er rimelige, men “følge min udvikling” er egentlig bredere end de viste AC. Måske skal der senere være en anden story om statistik/grafer.

User storyens formål behøver ikke betyde, at alle funktioner, der understøtter formålet, skal med i samme story. En user story bruges til at planlægge vores arbejde og må derfor ikke være for stor.

Som bruger skal systemet kunne håndtere 500 samtidige brugere…

Det er et non-funktionelt krav, ikke en user story.

Det er også mærkeligt at give systemet en brugerrolle.

Man kunne have:

Systemet skal kunne håndtere mindst 500 samtidige brugere.

Det er et systemkrav.

Som bruger vil jeg kunne oprette en konto, logge ind, ændre mit kodeord, uploade et profilbillede og slette min konto…

Her er problemet meget tydeligt: fem funktioner i én story.

Det er scope creep i miniature.

Den kan sandsynligvis deles op i flere stories.

Som udvikler vil jeg have en User-klasse med en save()-metode…

Det er teknisk design/implementation.

Det kan være en task eller en teknisk beslutning, men ikke en user story om brugerens behov.

Vigtig pointe: “Som udvikler…” gør ikke automatisk noget til en user story.

Som hundeejer vil jeg have et Google Maps-kort med blå markører…

Her er brugerens behov måske reelt nok:

finde hundeluftere.

Men storyen foreskriver allerede løsningen:

Google Maps + blå markører.

Man kunne spørge:

“Ved vi, at brugeren faktisk har brug for Google Maps?”

Måske er kortet en rigtig god løsning. Men det bør være et designvalg, der udspringer af et behov, ikke nødvendigvis selve user storyen.

Som bruger vil jeg kunne booke en hundelufter, så jeg kan få min hund luftet, når jeg er på arbejde.

Meget fin story.

AC’erne beskriver forskellige scenarier:

• ledig hundelufter
• allerede booket
• booking er oprettet

Her begynder man at kunne forestille sig egentlig UAT.

Selve user storyen er fin:

Som bruger vil jeg kunne booke en hundelufter…

Men AC’erne er dårlige:

• Det skal virke.
• Det skal være brugervenligt.
• Det skal se godt ud.

Problemet er, at de ikke giver os en klar måde at afgøre, hvornår storyen er færdig.

“Det skal virke” fortæller os ingenting.

“Brugervenligt” kan godt være et legitimt non-funktionelt krav, men det skal operationaliseres, hvis vi vil kunne teste det.

Som bruger vil jeg kunne trykke på knappen “Gem”, så jeg kan gemme noget.

Der er teknisk set en bruger og en funktion, men hvorfor vil brugeren gemme noget?

Vi mangler konteksten og værdien.

God diskussion: Er “Gem” overhovedet en selvstændig story, eller er det en del af en større funktion?

Som bruger vil jeg kunne søge efter ledige hundeluftere…

De første tre AC er funktionelle.

Det sidste:

Søgeresultaterne skal vises inden for 2 sekunder.

er et non-funktionelt krav, som er blevet knyttet til denne user story som et acceptkriterium.

Det er helt legitimt.

Når vi vurderer en user story, kan vi spørge:

• Hvem er brugeren?
• Hvad vil brugeren kunne?
• Hvorfor vil brugeren det?
• Er funktionen afgrænset?
• Beskriver vi et behov eller en bestemt teknisk løsning?
• Kan vi ud fra acceptkriterierne afgøre, hvornår storyen er færdig?
• Kan vi faktisk teste acceptkriterierne?

Og husk:

En user story er et kort, fælles udgangspunkt for en samtale om, hvad der skal bygges og hvorfor.

Acceptkriterierne gør derefter intentionen konkret nok til, at vi kan afgøre, om resultatet lever op til den.

User Accept Test (UAT) tager udgangspunkt i acceptkriterierne.