Sådan skriver du fremragende acceptansekriterier (med eksempler)

Hvor mange gange har du set udviklere og testere diskutere, hvordan en bestemt funktion burde fungere? Hvad med de forvirrede ansigter hos udviklere, der ikke var sikre på, hvordan de skulle bygge den funktion, du havde bedt om? Begge dele er ret almindelige problemer i softwareverdenen, og heldigvis har du et stærkt værktøj i dit arsenal til at løse dem – acceptkriterier.

I denne guide gennemgår jeg dette formats karakter, når det gælder nedskrivning af krav, forklarer deres rolle i produktstyring og viser dig, hvordan du skriver gode acceptkriterier.

Indholdsfortegnelse

Hvad er acceptkriterier?

Hvad er formålet med at skrive acceptkriterier?

Hvordan bør velskrevne acceptkriterier se ud?

Almindelige formater for acceptkriterier

Hvad er acceptkriterier
(og hvor passer de ind i Agile/Scrum?)

I den agile metode er et acceptkriterium den mindste enhed af et funktionelt krav eller designkrav, som agile produktchefer (eller forretningsanalytikere) føjer til deres historier for tydeligt at kommunikere de forskellige tilstande og den adfærd, som de funktioner, teamet planlægger at bygge, skal have.

Teknisk set kan du bruge acceptkriterier, hvor du vil. Traditionelt er de dog en del af brugerhistorier, som er komponenter i agile epics.

For bedre at forstå acceptkriterier kan vi først genopfriske vores hukommelse og gennemgå elementerne i dette hierarki for at se, hvad hvert enkelt bruges til.

Store funktionselementer

Store funktionselementer er opgaver, der indeholder overordnede funktionelle og ikke-funktionelle krav til en stor funktion eller en gruppe af funktioner, der er relateret til hinanden. Et stort funktionselement dækker normalt et helt anvendelsestilfælde for dine kunder og indeholder alle de underliggende funktioner og muligheder, du skal implementere for at dække det pågældende anvendelsestilfælde.

Forestil dig, at du var en del af produktteamet hos Spotify, og at du ønskede at udvide brugen af appen ved at tilføje et nyt anvendelsestilfælde for de mennesker, der er på farten og ikke har adgang til internettet.

For at dække dette anvendelsestilfælde kan du overveje at tilføje en ny stor funktion kaldet “offlinefunktion til Spotify”, og den kan blive et stort funktionselement i din produktbacklog, der indeholder alle de overordnede krav til at lade brugerne lytte til musik uden internetforbindelse samt flere brugerhistorier med kravene til bestemte dele af denne funktion.

Brugerhistorier

Brugerhistorier er mindre i omfang og repræsenterer et enkelt, afgrænset stykke funktionalitet inden for det store funktionselement. De er små arbejdsopgaver, som det agile team kan forpligte sig til at levere inden for en enkelt iteration.

En af de vigtigste egenskaber ved en brugerhistorie er, at den funktionalitet, den repræsenterer, skal være komplet og potentielt anvendelig.

Hvis du for eksempel bygger en app til onlinefillagring og vil give dine brugere mulighed for at omdøbe de filer, de har uploadet, skal du udføre arbejde i brugerfladen (brugergrænsefladen og brugeroplevelsen ved omdøbning) og i det bagvedliggende system (lagring af det nye navn).

For at funktionen kan være komplet og anvendelig, skal du færdiggøre begge opgaver og forbinde delene i brugerfladen og det bagvedliggende system med hinanden. Dit team ville udføre alt dette inden for rammerne af en enkelt brugerhistorie.

Hvis du kun udførte arbejdet i det bagvedliggende system, ville opgaven ikke være en rigtig historie, da den ville indeholde en leverance, der ikke er komplet og anvendelig.

For at fortælle udviklingsteamet, hvordan funktionen skal se ud, og hvordan den skal fungere, skriver produktejere acceptkriterier for historien.

Acceptkriterier for brugerhistorier

Til sidst har vi de mindste elementer i hierarkiet over krav til softwareprodukter – acceptkriterier. De repræsenterer individuelle brugsscenarier for denne funktionalitet eller informationsstykker, som udviklingsteamet finder vigtige, når historien implementeres.

I eksemplet ovenfor ville et acceptkriterium være at åbne et tekstfelt med filens navn udfyldt på forhånd, hvis brugeren klikker på knappen ✏️Omdøb for den fil, som vedkommende har uploadet.

Definition af færdig (ja, den adskiller sig fra acceptkriterier!)

Nogle gange forveksler produktejere (især dem, der er relativt nye i denne Scrum-rolle) definitionen af færdig med acceptkriterier.

Helt ærligt var det også ret forvirrende for mig i begyndelsen, fordi begge dele er “kriterier til at kontrollere, om funktionen er komplet”.

Den eneste forskel er, at definitionen af færdiggørelse repræsenterer fuldstændighed med hensyn til teamets udviklingsprocesser.

Mens acceptansekriterierne repræsenterer funktionelle krav (hvordan funktionen skal se ud og opføre sig).

Det betyder, at definitionen af færdiggørelse vil forblive den samme for alle de brugerhistorier, som teamet implementerer, medmindre de beslutter at ændre den under retrospektiverne. Acceptansekriterierne er derimod unikke for hver brugerhistorie, da de forklarer, hvordan funktionen skal fungere.

Bemærk: Nogle værktøjer til produktstyring giver dig mulighed for at have både definitionen af færdiggørelse og acceptansekriterier på dine brugerhistorier.

Nu hvor vi husker, hvad epics og brugerhistorier handler om, og hvordan acceptansekriterier hænger sammen med dem, kan vi gå videre og forstå, hvorfor produktejere overhovedet skriver acceptansekriterier.

Hvad er formålet med at skrive acceptansekriterier?

Kan jeg ikke bare skrive en beskrivelse af en brugerhistorie på den måde, jeg ønsker, uden at inkludere acceptansekriterier? Hvad er fordelen ved overhovedet at skrive acceptansekriterier?

Selvfølgelig kan du skrive dine brugerhistorier på den måde, du ønsker. Jeg anbefaler dog, at du bruger acceptansekriterier som en måde at formulere dine krav på, da dette format har en lang række fordele. Her er et par stykker, du kan overveje.

De fremmer adfærdsdrevet tænkning

Hvis du vælger BDD-formatet til acceptansekriterier (mere om det senere), vil dine acceptansekriterier beskrive dine kunders rejse, når de bruger den pågældende funktion.

Det smukke ved denne tilgang er, at du flytter din tankegang væk fra tørre tekniske krav og begynder at se på funktionen fra brugerens synspunkt. På den måde kan du visualisere, hvad de oplever og føler, når de interagerer med din funktion.

Det er meget almindeligt, at produktejeren indser, at den funktionalitet, de har forestillet sig, ikke er den bedste, når de først ser på den fra brugernes synspunkt.

Det har jeg også oplevet flere gange. Da jeg for eksempel udarbejdede krav til en matematisk formeleditor (den var en del af et SaaS-produkt til finansiel analyse, som vi byggede på det tidspunkt), ønskede jeg, at redigeringsprocessen skulle se sådan ud:

• En redigeringsknap ved siden af formlen.
• Et klik på redigeringsknappen ville gøre formularfeltet redigerbart og vise knapperne ✅ Gem og ❎ Annuller .
• Et klik på en af dem ville afslutte redigeringstilstanden, og enten den nye gemte version eller den gamle version af formlen ville blive vist dér, afhængigt af brugerens valg.

Den adfærd virker logisk, ikke?

Jo, men ikke før jeg begyndte at skrive scenarier ned for analytikere, der brugte den, og fandt en betydelig brugervenlighedsfejl. Analytikerne sidder normalt og justerer formlen ved at foretage små ændringer i den og se på beregningsresultatet, indtil de får den formel, de ønsker.

Den måde, jeg havde forestillet mig, at redigeringen skulle fungere på, ville være ekstremt irriterende for mine målbrugere, da de skulle gå ind i og ud af redigeringstilstanden 20-30 gange i træk. Så snart jeg indså fejlen, ændrede jeg derfor hurtigt acceptansekriterierne og bad om at få bygget en formeleditor, hvor man kunne foretage ændringer i realtid.

De hjælper med at skabe én fælles sandhedskilde

Som “ung” produktchef var min største udfordring at kommunikere produktkrav til personer med forskellige fagligheder eller endda til forskellige teams. Problemet var, at hver af dem forstod kravene forskelligt, og kommunikationen mellem dem blev til et uklart rod.

Det var på det tidspunkt, at en erfaren produktchef foreslog, at jeg anvendte konceptet med én fælles sandhedskilde ved at formulere mine produktkrav på en meget klar måde (det er noget, som AI i kravindsamling kan hjælpe med), kommunikere dem til alle og bede dem om kun at basere deres arbejde på det, der stod skrevet dér.

Det blev en kæmpe succes, eftersom alle havde den samme forståelse af, hvordan funktionen skulle fungere, og hvis der opstod uenigheder, kunne de vende tilbage til kravet.

Acceptansekriterier er en fremragende måde at skabe en enkelt sandhedskilde på, da de beskriver funktionaliteten på en klar og letlæselig måde og har en høj detaljeringsgrad (da de bør dække alle de vigtigste detaljer ved funktionaliteten).

De forbedrer kvaliteten af acceptancetestningen

For softwareingeniører fungerer acceptansekriterier som de produktkrav, de følger, når de udvikler funktionaliteten. For dit kvalitetsteam har acceptansekriterier derimod et par ekstra funktioner:

De hjælper med at prioritere testcases. Hvis dit softwaretestteam har mange testcases for den pågældende funktionalitet, og der ikke er tid nok til at gennemgå dem alle, vil de prioritere og køre de testscenarier, der matcher acceptansekriterierne, først, da de beskriver de mest kritiske brugerflows.

De fungerer som en accepttjekliste. Dette punkt gælder både QA-teams og produktejere, der skal acceptere funktionaliteten. Acceptansekriterier fungerer, som navnet antyder, som en tjekliste, når funktionalitetens status skal afgøres som godkendt eller ikke godkendt. Hvis et eller flere af acceptansekriterierne ikke er opfyldt, genåbner QA-teamet brugerhistorien og beder udviklingsteamet om at tilføje den manglende funktionalitet.

For at opsummere er acceptansekriterier uvurderlige værktøjer i hænderne på produktejere, når produktkrav skal kommunikeres korrekt. Men hvordan skriver man gode acceptansekriterier? Det hjælper jeg dig med nu.

Hvordan ser velformulerede acceptansekriterier ud?

Kvaliteten af de acceptansekriterier, du skriver, har direkte indflydelse på kvaliteten af den funktionalitet, dit team leverer. Med en klar forståelse af, hvad der skal bygges, og hvordan det skal testes, vil dit team bygge funktionaliteten på den måde, du har forestillet dig, med et minimum af problemer.

Hvis du vil være dygtig til at skrive acceptansekriterier, skal du være opmærksom på følgende.

Klarhed

Den største fejl, en produktejer kan begå, er at skrive uklare og vage acceptansekriterier. Du kan godt glemme forestillingen om en fælles forståelse, hvis folk kan fortolke det, du har skrevet, på flere forskellige måder.

For at se, hvor stor en forskel det gør, vil jeg vise dig et eksempel.

Hvad forstod du ud fra denne sætning? Kan du fortælle mig, hvordan hæveautomaten vil bruge korttypen til at afgøre, om brugeren skal godkendes eller ej? Vil hæveautomaten godkende brugeren, hvis alle disse kriterier er opfyldt på samme tid, eller er det nok kun at opfylde ét af dem?

Hvis du giver dette acceptansekriterium til dine ingeniører, vil de bombardere dig med spørgsmål og bede dig om at gøre dine krav tydeligere. Lad os nu gøre det bedre.

Det ser meget bedre ud, ikke? Med dette acceptansekriterium har vi også givet svarene på alle ovenstående spørgsmål. Hæveautomaten skal understøtte den korttype, brugeren har indsat, og alle tre kriterier skal være opfyldt på samme tid, for at hæveautomaten kan godkende brugeren.

Professionelt tip: Gør dine acceptansekriterier SMARTe (specifikke, målbare, opnåelige, relevante og testbare). Ja, jeg har ændret det sidste til testbart, da det er en vigtig egenskab ved effektive acceptansekriterier.

Læsevenlighed

Ud over at undgå uklarhed i dine acceptansekriterier bør du også holde dem enkle og undgå smarte udtryk eller komplekst sprog.

Jeg er sikker på, at du har et team af højtuddannede stjerner, der nemt kan læse og forstå de mest avancerede og komplekse ord og vendinger på engelsk, men du ønsker ikke at spilde deres mentale kapacitet på at afkode dine tekster.

Så i stedet for dette.

Så sig dette.

Jeg går ud fra, at du ikke engang gad læse det første acceptansekriterium helt, fordi du heller ikke ønskede at spilde din tid og mentale kapacitet!

Dækning af scenarierne

Det er detaljerne, der tæller. Nogle gange opdager man, at man har overset et problematisk tilfælde i sin funktion, når man er meget langt i udviklingsfasen og er nødt til at oprette en opfølgende forbedringsopgave eller endda lave det hele om.

Lyder det bekendt?

Jo flere tilfælde du tager højde for i dine acceptkriterier fra starten, desto mindre er risikoen for, at du står over for det scenarie med dine backlog-elementer.

Lad os nu se på acceptkriterierne nedenfor.

Kan du se, om der er noget mærkeligt her? Ved første øjekast er kravet klart: Du tilføjer e-mailadressen, trykker på send, og personen får adgang. I virkeligheden har vi ikke taget højde for en lang række tilfælde her:

• Hvis e-mailadressen allerede findes på listen over brugere, der har adgang til dokumentet, bør du måske vise en fejlmeddelelse, der fortæller brugeren det.
• Du sender en invitation pr. e-mail til brugeren, så det er måske værd at vise, om vedkommende har accepteret invitationen eller ej, på din delte liste.
• Hvis vedkommende ikke har accepteret invitationen, er det måske værd at tilføje en knap til at “sende invitationen igen”.

Der er også negative tilfælde, hvor du præciserer funktionens adfærd, når noget er tomt, eller der er opstået en fejl.

Aktiv brug af visuelle hjælpemidler

Var de acceptkriterier, jeg delte ovenfor, helt klare for dig? Da jeg talte om feltet “Tilføj personer og grupper”, forstod du så tydeligt, hvad det handlede om?

Nogle gange er ord ikke nok til at skabe klarhed om kravene i dit team, og det er bedre at vise dem end at fortælle om dem. Lad mig nu forbedre disse acceptkriterier en smule.

Har jeg ret i at antage, at du nemt ville have forstået, hvad jeg talte om med disse acceptkriterier, hvis du så billedet og mine kommentarer side om side? Det tror jeg, du ville.

Det dækker “acceptkriterierne for acceptkriterier” — lad os nu se på de forskellige typer og formater, som produktteams bruger til dem.

Almindelige formater for acceptkriterier

Jeg vil være ærlig over for dig. Jeg bruger sjældent det samme format i alle mine brugerhistorier. Årsagen er, at forskellige formater for acceptkriterier er velegnede til forskellige anvendelsestilfælde, og det er ikke altid den bedste idé altid at tvinge sig selv til at bruge det samme format.

Derfor vælger jeg formatet ud fra historien og den type information, jeg ønsker at skrive i dens acceptkriterier.

Lad os nu se på nogle af de almindelige formater og deres tilsvarende eksempler på acceptkriterier.

BDD-format

BDD står for adfærdsdrevet udvikling, og det er en ramme, der tilskynder softwareudviklere og medlemmer af produktteams til at definere krav baseret på den måde, deres slutbrugere vil interagere med funktionen på.

Som en måde at skrive krav på baseret på brugeradfærd følger acceptkriterierne for BDD denne specifikke skabelon:

Givet: Forudsætningen for det specifikke scenarie for brugeradfærd.

Når: Den handling, som brugeren udfører.

Så: Resultatet af handlingen.

Hvis du derfor ville forklare, hvordan hævefunktionen i en hæveautomat fungerer, ville dine acceptkriterier se sådan ud:

Denne type acceptkriterier med givet/når/så er fremragende, når du vil skabe empati for brugernes behov i dit team ved at lægge vægt på brugerens perspektiv.

Tjeklisteformat

I modsætning til BDD-formatet (også kaldet et “scenariebaseret” format) viser dette format ikke slutbrugerens synspunkt. Det handler i stedet mere om at forklare de bestemte regler, som funktionens forretningslogik skal følge (et alternativt navn for dette format er “regelbaseret”). Sådan ser de ud.

Dette format passer bedst, når den logik, du vil forklare, er kompleks, da det hjælper dig med at opdele den i flere små regler, som er lettere at forstå og implementere. 

Flowformat

Dette er sandsynligvis det format, jeg bruger mest.

Flowformatet minder om BDD-formatet, da det også viser brugerens perspektiv. I modsætning til BDD håndhæver det dog ikke en streng struktur (Given/When/Then). Du kan derfor frit beskrive de trin, som brugeren gennemgår, på den måde du ønsker.

Sådan ville tilmeldingsprocessen se ud med dette format.

Flowformatet vil være den bedste løsning, hvis du gerne vil skabe empati med brugeren (ligesom med BDD), men ikke rigtig ønsker at følge en streng struktur.

Hold alle på samme side med acceptkriterier

Acceptkriterier er effektive værktøjer i hænderne på produktejere, fordi de gør det muligt at skabe én fælles sandhedskilde og holde deres teammedlemmer på linje med deres vision for den pågældende funktion.

Hvis du vil have flere vejledninger som denne og andre gode ressourcer for folk, der arbejder med produkter, kan du abonnere på vores nyhedsbrev!