Brugerhistorier: sådan beskriver I funktioner, så de bliver bygget rigtigt

Ejeren af en klinik skriver i kravene til sit nye bookingsystem: “Kunderne skal kunne booke online.” Udvikleren bygger en kalender, hvor kunden vælger en tid. Ved første demo viser det sig, at kunderne skal vælge behandler, at nogle behandlinger kræver forundersøgelse, at der skal betales depositum, og at kunden skal have en SMS dagen før. Ingen af delene var forkerte. Sætningen var bare så kort, at alle fyldte hullerne ud med deres egne antagelser. Brugerhistorier med acceptkriterier er det værktøj, der lukker de huller, før koden skrives.

Denne guide er skrevet til jer, der skal købe software, og som vil beskrive jeres behov så præcist, at leverandøren bygger det, I mener. Den gælder både for apps, webapps, portaler og hjemmesider med funktioner.

Hvad er en brugerhistorie?

En brugerhistorie beskriver én ting, en bestemt bruger vil kunne gøre, og hvorfor. Formatet har tre dele: rollen, handlingen og gevinsten. Rollen sikrer, at I tænker på, hvem funktionen er til. Handlingen beskriver, hvad de vil gøre. Gevinsten, “så …”-delen, er den vigtigste, fordi den fortæller designeren og udvikleren, hvilket problem funktionen løser, så de kan foreslå en bedre løsning, hvis der findes en.

Skabelon: Som [rolle] vil jeg [handling], så [gevinst]. Eksempel: Som kunde vil jeg få en SMS dagen før min tid, så jeg ikke glemmer den.

Brugerhistorier kommer fra agil softwareudvikling, og de beskrives ofte med de tre C’er: Card, Conversation og Confirmation. Kortet er selve sætningen. Samtalen er den dialog mellem jer og teamet, hvor detaljerne afklares. Bekræftelsen er acceptkriterierne, som afgør, hvornår historien er færdig. En historie er altså en invitation til en samtale, og det er samtalen, der skaber den fælles forståelse.

Hvordan skriver man en god brugerhistorie?

Den mest brugte tjekliste hedder INVEST. Hvis en historie opfylder de seks punkter, er den typisk klar til at blive estimeret og bygget. Brug listen, når I gennemgår jeres udkast:

• Independent (uafhængig): historien kan bygges og leveres for sig selv.
• Negotiable (til forhandling): den beskriver behovet og lader løsningen være åben for dialog.
• Valuable (værdifuld): den giver værdi for en bruger eller for forretningen.
• Estimable (kan estimeres): teamet forstår den godt nok til at vurdere størrelsen.
• Small (lille): den kan bygges og testes på få dage.
• Testable (kan testes): der er klare kriterier for, hvornår den virker.

Eksempler på brugerhistorier fra et bookingsystem

Her er 12 brugerhistorier fra et typisk bookingsystem til en klinik eller en servicevirksomhed. Læg mærke til, at der er tre roller: kunden, medarbejderen og administratoren. Mange glemmer de to sidste, selv om det er dem, der bruger systemet hver dag.

Hvad er acceptkriterier, og hvordan skriver man dem?

Acceptkriterier er de konkrete betingelser, der skal være opfyldt, før en historie er færdig. De er jeres vigtigste beskyttelse som kunde, fordi de gør “færdig” til noget, I kan teste. Et populært format er Givet–Når–Så, på engelsk Given–When–Then: givet en bestemt situation, når brugeren gør noget, så sker der dette. Her er kriterierne til historien om aflysning:

• Givet at tiden er mere end 24 timer væk, når kunden trykker “Aflys” i bekræftelsesmailen, så frigives tiden, og kunden får en kvittering.
• Givet at tiden er mindre end 24 timer væk, når kunden prøver at aflyse, så vises klinikkens telefonnummer og en forklaring på reglen.
• Givet at kunden har betalt depositum, når tiden aflyses rettidigt, så refunderes depositum automatisk.
• Givet at tiden er aflyst, så kan en anden kunde booke den med det samme.
• Givet at en tid aflyses, så får behandleren besked i sin oversigt.

Bemærk, hvor mange spørgsmål fem korte kriterier besvarer: hvad 24-timersreglen betyder i praksis, hvad der sker med betalingen, og hvem der får besked. Hvert af dem ville ellers være dukket op som en diskussion ved demoen eller som en fejl efter lanceringen. Kriterierne er også det, I tester efter, når I godkender leverancen, og de er et godt udgangspunkt for en brugertest.

Hvad er forskellen på epics, brugerhistorier og opgaver?

Hvordan prioriterer man brugerhistorier med MoSCoW?

MoSCoW er den mest udbredte metode til at prioritere en liste af brugerhistorier. Hver historie placeres i én af fire kategorier. Den svære del er at være ærlig om, hvad der er et must. Et nyttigt spørgsmål er: “Kan vi lancere uden den, og vil nogen så bruge løsningen?” Er svaret ja, er det ikke et must. Metoden stammer fra DSDM-rammeværket, som anbefaler, at must-historierne højst udgør omkring 60 % af indsatsen, så der er luft til det uventede.

Hvordan bliver brugerhistorier til en fast pris?

En prioriteret liste af brugerhistorier er det bedste grundlag for en fast pris, fordi både I og leverandøren kan se præcis, hvad der er med. Vores pakker er bygget op om antal funktioner: Small har 12 funktioner og 1 integration til 18.000 kr. for web eller 28.000 kr. for en app, Medium har 24 funktioner og Large 36. En must-historie svarer ofte til én funktion, så en god liste gør det let at se, hvilken pakke der passer. Se detaljerne under priser, og læs mere om forskellen på fast pris og timepris.

Hvilke fejl ser vi oftest i brugerhistorier?

• Rollen er “bruger”. Skriv hvilken bruger: kunde, medarbejder, administrator, revisor.
• Gevinsten mangler. Uden “så …” kan teamet ikke foreslå en bedre løsning.
• Historien beskriver en skærm frem for et behov, for eksempel “en side med en dropdown”.
• Historien er for stor. “Som kunde vil jeg håndtere mine bookinger” er en epic.
• Ingen acceptkriterier, så “færdig” bliver et spørgsmål om smag.
• Alt er must. Så er intet prioriteret, og budgettet styrer i stedet for værdien.
• Fejlsituationer er glemt: hvad sker der, når betalingen fejler, eller tiden er taget?

Skabelon: sådan kommer I i gang med jeres brugerhistorier

1. List alle brugertyper, der skal bruge løsningen, inklusive jeres egne medarbejdere.
2. Skriv for hver brugertype de 3–5 vigtigste ting, de skal kunne gøre.
3. Formulér hver ting som “Som [rolle] vil jeg [handling], så [gevinst]”.
4. Del store historier op, til hver kan bygges på få dage.
5. Tilføj 3–6 acceptkriterier til alle must-historier.
6. Prioritér med MoSCoW, og vær streng med must-kategorien.
7. Skriv de ikke-funktionelle krav som en kort liste: sikkerhed, hastighed, tilgængelighed, hosting.
8. Gennemgå listen med jeres leverandør, før I beder om en fast pris.

Brugerhistorier skrives bedst sammen, og en discovery-workshop er det oplagte sted at gøre det. Foretrækker I et mere klassisk dokument, kan historierne indgå direkte i vores skabelon til kravspecifikation. Og vil I forstå, hvordan historierne bruges i selve udviklingsforløbet, så læs guiden til agil vs vandfald. Har I allerede en liste, så send den til os, og få et skriftligt tilbud til fast pris inden for 24 timer.