User stories: sådan beskriver du funktioner, så udvikleren forstår dem

En user story er en kort beskrivelse af hvad en bestemt bruger skal kunne gøre i et system, og hvorfor. Gode user stories følger formen "Som [rolle] vil jeg [handling], så [formål]" og har nogle få acceptkriterier der beskriver hvornår opgaven er løst. Herunder får du seks trin, fem før- og efter-eksempler og en tjekliste, så du kan skrive dem selv uden at kunne kode.

Jeg er freelanceudvikler, så jeg sidder typisk i den anden ende og skal bygge og sætte pris på det historierne beskriver.

Den korte version: fem dele der skal med

Har du styr på de fem dele, er du nået langt. Resten af guiden gør hver del præcis nok til at den kan bygges og prissættes. User stories bliver ofte skrevet i forprojektet, og du kan se hvor de passer ind i hele forløbet i et softwareprojekt.

Hvorfor en liste over funktioner ikke er nok

Mange starter med en liste: login, dashboard, rapporter, eksport. Listen fortæller hvad der skal findes, men ikke hvem der skal bruge det, eller hvad de prøver at opnå. To udviklere kan læse "rapporter" og bygge to helt forskellige ting, og begge kan med god ret sige at de har lavet det der stod.

En user story flytter fokus fra systemet til personen der bruger det, og det ændrer hvilke spørgsmål udvikleren stiller. I stedet for "hvilke kolonner skal rapporten have?" bliver spørgsmålet "hvad skal salgschefen beslutte ud fra den?". Det svar fører ofte til en enklere løsning end den du havde forestillet dig.

Ron Jeffries, en af folkene bag Extreme Programming, beskrev allerede i 2001 user stories med tre C'er: card, conversation og confirmation. Kortet er en påmindelse, samtalen afklarer detaljerne, og bekræftelsen er de test der viser at opgaven er løst. Pointen holder stadig: en user story er ikke en kontrakt, men en invitation til at tale om opgaven.

User stories er heller ikke forbeholdt Scrum. Den officielle Scrum Guide nævner dem slet ikke. De virker også i projekter med en fast plan og en fast pris, og forskellen på de to måder at styre et projekt på har jeg beskrevet i agil udvikling vs. vandfald.

Sådan skriver du en user story i seks trin

Trinene tager dig fra en løs idé til en historie som en udvikler kan stille præcise spørgsmål til.

1. Start med brugerne, ikke skærmbillederne

Lav en liste over de roller der skal bruge systemet før du skriver en eneste historie. Der er typisk flere end man tror: kunden, medarbejderen der behandler sagen, lederen der skal have overblik, og administratoren der opretter brugere og retter fejl.

Brug de navne I selv bruger, fx "lagermedarbejder" eller "bogholder". Undgå "brugeren" som ord for alle. Hver rolle har sine egne behov og ofte sine egne rettigheder, og det påvirker hvordan systemet skal bygges.

2. Beskriv handlingen som noget personen gør

Handlingen skal være et udsagnsord: finde, godkende, bestille, aflyse, sende. Skriv hvad personen gør, ikke hvad systemet har. "Som bogholder vil jeg have en fakturaside" siger ikke noget om hvad bogholderen skal kunne. "Som bogholder vil jeg godkende leverandørfakturaer" gør.

Hold dig til én handling pr. historie. Står der "og" i handlingen, har du sandsynligvis to historier.

3. Skriv formålet, også når det føles åbenlyst

"Så"-delen er den der oftest bliver sprunget over, og den der hjælper udvikleren mest. Formålet fortæller hvad der er vigtigt, og dermed hvad der kan forenkles. Skal kunden se sine fakturaer for at betale dem, for at sende dem videre til sin bogholder eller for at kunne slå en uenighed op? Tre forskellige svar giver tre forskellige løsninger.

Kan du ikke skrive et formål, så overvej om historien overhovedet skal med. Det er en af de billigste måder at skære i et projekt på.

4. Tilføj acceptkriterier

Acceptkriterier er de konkrete betingelser der skal være opfyldt før historien er færdig. De sikrer at du og udvikleren er enige om hvad "færdig" betyder. Tre til seks punkter er nok til de fleste historier. Har du brug for flere, er historien sandsynligvis for stor.

Skriv især undtagelserne ned: hvad sker der hvis søgningen ikke giver noget resultat, hvis betalingen fejler, eller hvis to personer retter det samme på én gang? Det er her tiden går i et projekt, og det er her misforståelserne opstår.

Nogle skriver kriterierne som Givet, Når, Så: "Givet at kunden har en aktiv booking, når kunden aflyser mere end 24 timer før, så bliver beløbet refunderet." Formen kaldes Gherkin og bruges i testværktøjer som Cucumber. Den er ikke nødvendig, men den tvinger dig til at tænke situation, handling og resultat igennem.

Gode acceptkriterier kan senere blive til automatiske tests der tjekker reglerne ved hver ændring, og det er en af grundene til at automatiserede tests sparer dig penge.

5. Del store historier op

En historie der dækker en hel del af systemet, fx "Som kunde vil jeg administrere min konto", kaldes ofte en epic. Den er fin som overskrift, men for stor til at sætte pris på. Bill Wakes huskeregel INVEST fra 2003 siger blandt andet at en god historie er lille og testbar.

Del efter brugerens arbejdsgang, ikke efter teknik. "Byg databasen" og "lav skærmbilledet" er udviklerens opgaver, og dem kan du hverken prioritere eller teste. Gode måder at dele på er:

• efter trin i arbejdsgangen: oprette, rette, slette
• efter regler: standardprisen først, rabatterne i en separat historie
• efter normalforløb og undtagelser: betalingen der lykkes, og betalingen der fejler

6. Prioritér hver historie

Giv hver historie én af tre prioriteter: skal med, bør med eller kan vente. Vær hård ved "skal med". Spørg om systemet kan bruges til sit vigtigste formål uden historien. Kan systemet det, hører historien ikke til i den bunke.

Sådan giver gode historier dig et mere præcist tilbud

En udvikler der skal give en pris, gætter på alt det der ikke står, og hvert gæt bliver til en buffer i tilbuddet. Med klare user stories kan udvikleren i stedet vurdere hver historie for sig, spørge ind til de uklare og pege på dem der koster meget i forhold til hvad de giver.

Acceptkriterierne er typisk den del der påvirker prisen mest. "Kunden kan aflyse en booking" ligner en lille opgave. "Kunden kan aflyse, får pengene tilbage efter reglerne, medarbejderen får besked, og tiden bliver ledig igen" er en større opgave. Til gengæld bliver den rigtige størrelse prissat nu og ikke opdaget midt i projektet.

Prioriteten gør resten. Når hver historie har en pris, kan du se præcis hvad første version koster, og flytte historier til "kan vente" indtil budgettet passer. Det er også her fast pris bliver realistisk: kan du beskrive hvad der skal være færdigt, og hvordan I tester det, kan en udvikler give en fast pris på det. Hvornår det ene eller det andet passer bedst, kan du læse i min gennemgang af fast pris og timepris.

To råd når du sender historierne ud:

• Send den samme version til alle du beder om et tilbud. Ellers kan du ikke sammenligne svarene.
• Forvent spørgsmål. En udvikler der vender tilbage med spørgsmål, har læst historierne. Et tilbud uden et eneste spørgsmål bør gøre dig lidt skeptisk.

Før og efter: fem typiske historier skrevet om

Her er fem historier som de ofte ser ud i første udkast, og hvordan de kan skrives om. Eksemplerne er lavet til denne artikel, men fejlene går igen i mange projekter.

Den vage historie

Før: "Som bruger vil jeg have et dashboard."

Hvem er brugeren, hvad skal oversigten vise, og hvad skal den bruges til? Udvikleren kan kun gætte.

Efter: "Som lagerchef vil jeg se hvilke varer der er under minimumsbeholdningen, så jeg kan bestille nye før de bliver udsolgt."

• Listen viser vare, nuværende beholdning og minimum.
• Varer med en beholdning på nul står øverst.
• Listen bliver opdateret så snart en ordre er sendt.

Løsningen forklædt som behov

Før: "Som administrator vil jeg have en knap der eksporterer fakturaer til Excel."

Historien beskriver en løsning, ikke et behov. Den kan godt være rigtig, men den lukker for et bedre forslag.

Efter: "Som bogholder vil jeg have månedens fakturaer over i regnskabsprogrammet uden at taste dem ind, så månedsafslutningen tager kortere tid."

Med formålet på plads kan udvikleren foreslå en direkte integration til fx e-conomic eller Dinero i stedet for en fil der skal flyttes manuelt hver måned. Måske er Excel-filen stadig det billigste svar. Nu vælger du det bare med åbne øjne.

Historien der rummer alt

Før: "Som kunde vil jeg kunne oprette en konto, logge ind, nulstille min adgangskode, rette mine oplysninger og slette min konto."

Det er fem historier i én, og de har vidt forskellige regler. Sletning alene rejser spørgsmålet om hvad der skal ske med ordrer og fakturaer, som virksomheden typisk skal gemme af hensyn til bogføringen.

Efter: fem separate historier, fx:

• "Som kunde vil jeg oprette en konto med min e-mail, så jeg kan følge mine ordrer."
• "Som kunde vil jeg nulstille min adgangskode via e-mail, så jeg kan komme ind igen hvis jeg har glemt den."
• "Som kunde vil jeg slette min konto, så mine oplysninger ikke ligger hos jer længere."

Nu kan de prioriteres hver for sig. Måske klarer kundeservice sletning manuelt i første version.

Den tekniske historie

Før: "Som udvikler vil jeg sætte en database op."

Det er en teknisk opgave, ikke en user story. Ingen af dine brugere har brug for en database. De har brug for det databasen gør muligt.

Efter: Slet historien. Databasen bliver bygget som en del af de historier der har brug for den. Lad udvikleren styre de tekniske opgaver, og skriv dine historier ud fra hvad brugerne skal kunne.

Historien uden undtagelser

Før: "Som kunde vil jeg kunne aflyse min booking."

Det lyder færdigt, men de vigtigste spørgsmål står der ikke svar på: hvornår må kunden aflyse, og hvad sker der med pengene?

Efter: "Som kunde vil jeg aflyse min booking, så jeg ikke betaler for en tid jeg ikke kan bruge."

• Aflyser kunden mere end 24 timer før, bliver hele beløbet refunderet.
• Aflyser kunden senere, bliver intet refunderet, og kunden får det at vide før aflysningen bekræftes.
• Medarbejderen får besked, og tiden bliver ledig for andre kunder.

Hvornår du har brug for mere end historier

User stories er gode til at beskrive hvad brugerne skal kunne. De er dårligere til resten, og resten påvirker ofte prisen lige så meget.

• Krav til hastighed, sikkerhed og drift passer dårligt ind i formen. Hvor data skal ligge, og hvad det koster hvis systemet er nede en time, hører til i et separat afsnit. Min skabelon til en kravspecifikation har et afsnit til netop det.
• Komplicerede regler, fx en prismodel med rabatter, abonnementer og undtagelser, bliver tydeligere som en tabel med eksempler end som tyve historier.
• Integrationer kræver at udvikleren ved hvilke systemer der skal tale sammen, og gerne har adgang til deres dokumentation.
• Udseende og flow forklares bedre med en hurtig skitse end med tre afsnit tekst.

Du behøver heller ikke skrive alt som user stories. "Ret telefonnummeret i bunden af siden" er en opgave, ikke en historie, og det er helt fint. Er der tale om en enkelt ny funktion i et system du allerede har, er en kort beskrivelse og et opkald ofte nok.

Skal du have hjælp til at skrive dem? Har du en produktansvarlig der kender forretningen og har tid, er det som regel bedst at vedkommende skriver første udkast, og at en udvikler bagefter gennemgår dem. Er der mange åbne spørgsmål, er et betalt forprojekt hvor I skriver dem sammen, ofte billigere end at gætte sig frem til et tilbud.

Næste skridt: tjek dine historier før du sender dem

Når dine historier består tjekket, er de klar til at blive sat pris på. På siden om priser og forprojekter kan du se hvordan jeg sætter priser sammen, og hvad der sker før et projekt går i gang.

Ofte stillede spørgsmål

Hvem skal skrive user stories, kunden eller udvikleren?+

Den der kender brugerne bedst, bør skrive første udkast, og det er som regel dig som kunde. Udvikleren er god til at finde huller, dele historier op og spørge ind til undtagelser, men kan ikke gætte sig til dine arbejdsgange. Det bedste resultat kommer typisk når I gennemgår historierne sammen, fx i et forprojekt.

Skal user stories skrives på engelsk?+

Nej. Skriv dem på det sprog dine brugere og din udvikler taler til daglig. På dansk bliver formen "Som [rolle] vil jeg [handling], så [formål]". Engelsk er kun nødvendigt hvis nogen i projektet ikke læser dansk, fx et udviklingsteam i udlandet. Det vigtigste er at rollerne hedder det samme som i jeres hverdag.

Hvilket værktøj skal jeg bruge til user stories?+

Et regneark eller et delt dokument er nok til de fleste projekter. Værktøjer som Jira, Linear, Trello eller GitHub Issues er nyttige når udviklingen er i gang og historierne skal følges fra idé til færdig, men de gør ikke historierne bedre. Start enkelt, og flyt dem over i et værktøj når udvikleren foreslår det.

Kan jeg ændre mine user stories undervejs?+

Ja, og det er en del af idéen. En historie er udgangspunktet for en samtale, og nye erkendelser undervejs er normale. Har du en aftale om fast pris, skal ændringer dog aftales og prissættes før de bliver bygget. Nye historier eller ændrede acceptkriterier er det tydeligste grundlag for den snak.