Sådan skriver du acceptkriterier i Jira – med praktiske eksempler

”Kunder kan ændre deres notifikationsindstillinger” lyder som en tydelig Jira-sag, indtil nogen begynder at bygge den. Gemmes en ændring med det samme? Hvad sker der, hvis det mislykkes at gemme? Er indstillingen der stadig i morgen? Hvilke mails påvirkes?

Acceptkriterier gør åbne spørgsmål til aftalte, observerbare resultater. De hjælper dem, der bestiller, bygger og gennemgår en ændring, med at arbejde ud fra de samme forventninger.

I denne vejledning udvikler vi kriterier for en fiktiv kundeportalfunktion, forbedrer uklare krav og tilføjer en praktisk tjekliste til Power Packs Definition of Done & AC-værktøj. Du behøver ikke et særligt skriveformat for at starte. Tydelige betingelser og resultater er nok.

Hvad er acceptkriterier?

Acceptkriterier beskriver de betingelser, et bestemt stykke arbejde skal opfylde for at blive accepteret. De fokuserer på det forventede resultat af netop det arbejde. Atlassian adskiller dem fra Definition of Done, som beskriver den bredere kvalitetsstandard for afsluttet arbejde. Se Atlassians vejledning om acceptkriterier.

I vores eksempel er ”Et gemt notifikationsvalg forbliver valgt, efter at kunden logger ind igen” et acceptkriterium. ”Implementeringen er gennemgået” hører til den fælles Definition of Done.

Forskellen holder begge lister nyttige. Acceptkriterierne forklarer, om funktionen gør det, teamet har aftalt. Definition of Done forklarer, om arbejdet opfylder teamets bredere standard for færdiggørelse.

Ingen af listerne behøver indeholde alle implementeringstrin. ”Opret et databasefelt” kan være en nødvendig udviklingsopgave, men fortæller ikke en kunde eller reviewer, om indstillingen opfører sig korrekt.

Start med ét kunderesultat

Vores fiktive sag hedder ”Lad kunder styre den ugentlige opsummeringsmail”. Det ønskede resultat er, at en indlogget kunde kan vælge, om vedkommende vil modtage en ugentlig opsummering, uden at ændre væsentlige kontobeskeder.

Før kriterierne skrives, aftaler teamet nogle beslutninger om omfang. Indstillingen har en udtrykkelig Save-knap. Kunden ændrer kun sin egen indstilling. Indstillingen påvirker opsummeringer, der endnu ikke er sat i kø. Beskeder, som allerede er i kø, er uden for denne sags leveringsregel.

Detaljerne er opfundet til eksemplet. Dit team bør beslutte sin faktiske adfærd frem for at kopiere dem som produktkrav.

En kort note om omfang kan forhindre, at en lang tjekliste skal bære al konteksten. I Jira-beskrivelsen registrerer teamet, at sagen omfatter én indstilling på siden med kontoindstillinger. Valg af leveringsdage, ændring af mailadresser og administration af andre kunders indstillinger er separat arbejde.

Nu kan kriterierne fokusere på de resultater, der fastslår, om netop denne ændring virker.

Skriv først det normale forløb

Start med den oplevelse, du forventer, at de fleste kunder følger. Beskriv startbetingelsen, handlingen og det observerbare resultat i almindeligt sprog.

For eksempel: ”Når en indlogget kunde slår ugentlige opsummeringer fra og gemmer korrekt, viser kontoindstillingerne opsummeringer som slået fra, når siden åbnes igen.” En reviewer kan skabe starttilstanden, udføre handlingen og undersøge resultatet.

Sætningen er mere nyttig end ”Indstillinger gemmes korrekt”. Den angiver, hvilken indstilling der ændres, hvornår ændringen træder i kraft, og hvordan den kan kontrolleres.

Teamet skal også dække den modsatte retning. En betjening, der kan slå opsummeringer fra, men ikke til, er ufuldstændig. Skriv et særskilt kriterium, når den omvendte adfærd fortjener sin egen verifikation.

Tving ikke uafhængige resultater ind i ét punkt. Lagring, tastaturbetjening, maillevering og fejlhåndtering kan alle være vigtige, men ét enormt kriterium gør det svært at vise, hvilken del der stadig kræver opmærksomhed.

Tilføj fejl- og grænsetilfælde

Det normale forløb antager, at lagringen lykkes. Spørg, hvad kunden skal se, når den antagelse er forkert.

Vores team vælger denne regel: hvis anmodningen om at gemme fejler, viser siden en fejl og ingen succesbekræftelse. Når siden åbnes igen, er den tidligere gemte indstilling stadig gældende. Det giver revieweren et konkret fejltilfælde at afprøve i teamets testmiljø.

Undersøg derefter funktionens grænse. Indstillingen for ugentlig opsummering må ikke stoppe en mail til nulstilling af adgangskode. Kundens valg skal også overleve en ny login-session. Det er forskellige hensyn og får derfor separate kriterier.

Undgå at skrive ”Alle kanttilfælde håndteret”. Navngiv de tilfælde, der betyder noget. En nyttig diskussion begynder ofte med tre spørgsmål: hvad kan fejle, hvad skal forblive upåvirket, og hvad sker der senere?

Hvis teamet ikke kan aftale et forventet resultat, skal den uafklarede beslutning registreres, før implementeringen når for langt. Et ubesvaret spørgsmål bliver ikke et brugbart kriterium, blot fordi det står i en tjekliste.

En gennemarbejdet tjekliste med acceptkriterier

Her er det første komplette udkast til den fiktive sag. Hvert punkt beskriver et resultat, som teamet kan verificere separat.

• Åbning af kontoindstillinger viser kundens aktuelt gemte indstilling for ugentlig opsummering.
• Efter at ugentlige opsummeringer er slået fra og gemt korrekt, viser genåbning af kontoindstillinger, at indstillingen er fra.
• Efter at ugentlige opsummeringer er slået til og gemt korrekt, viser genåbning af kontoindstillinger, at indstillingen er til.
• Efter vellykket lagring bevares indstillingen ved logout og nyt login.
• Hvis lagring fejler, vises en fejl, ingen succesbekræftelse vises, og genåbning af indstillinger viser den tidligere gemte indstilling.
• En kunde med indstillingen slået fra modtager ingen ugentlig opsummering, der sættes i kø efter den vellykkede lagring.
• En kunde med indstillingen slået til er fortsat berettiget til næste ugentlige opsummering efter de eksisterende planlægningsregler.
• At slå ugentlige opsummeringer fra forhindrer ikke kunden i at modtage en anmodet mail til nulstilling af adgangskode.

Leveringspunkterne afhænger af beslutningen om beskeder i kø. Teamet registrerer konteksten ved siden af sagen, så revieweren ikke antager, at indstillingen tilbagekalder mails, som allerede er ved at blive sendt.

Kriterierne kræver også en brugbar verifikationsmetode. For leveringsadfærden identificerer teamet, hvordan en opsummering udløses eller observeres i testmiljøet. Et kriterium kan være klart skrevet, men svært at verificere, hvis ingen har adgang til den nødvendige konto eller leveringsdokumentation.

Forbedr uklare kriterier, før du tilføjer dem

En hurtig gennemgang af formuleringerne forebygger ofte længere uenigheder senere. Læs hvert punkt, og spørg, om to personer kan fortolke succes forskelligt.

Det sidste eksempel beviser ikke brugervenlighed alene. Det erstatter én uklar sætning med én nyttig, begrænset kontrol. Bredere mål for brugervenlighed kan kræve research eller flere aftalte observationer.

Vær også forsigtig med opfundet præcision. Et krav om to sekunders svartid lyder målbart, men skaber en reel forpligtelse. Aftal betingelserne og begrundelsen for en ydelsesgrænse, før den medtages.

Læg kriterierne ind i Power Pack

Åbn Jira-sagen, og find kortet Definition of Done & AC. Vælg fanen Acceptance Criteria. Listen er adskilt fra fanen Definition of Done, så kontrollér den valgte fane, før du indtaster indhold.

For at tilføje ét kriterium skriver du titlen og vælger Add eller trykker Enter. Brug korte titler, der stadig bevarer det forventede resultat. Hvis et kriterium kræver omfattende kontekst, skal den ligge i Jira-beskrivelsen eller teamets linkede dokumentation.

For flere punkter vælger du Bulk Import og indsætter en Markdown-punktliste. Du kan kopiere eksemplerne ovenfor med en bindestreg og et mellemrum foran hvert punkt. Markdown-lister med afkrydsningsfelter understøttes også.

Gennemgå punkterne efter import. Handlingen føjer til den nuværende liste, så import af samme tjekliste igen kan oprette punkter, der allerede findes. Markerede Markdown-afkrydsningsfelter ankommer som færdige; start med umarkerede punkter, medmindre den aktuelle sags resultater faktisk er verificeret.

Hvis et punkt er forkert, skal I gennemgå erstatningsformuleringen sammen, tilføje det rettede punkt og slette det forældede via bekræftelsesdialogen. Hold sagens understøttende diskussion tydelig, når en ændring påvirker det aftalte omfang.

Gennemgå resultater, før de markeres færdige

Bed før implementering en person, der deltager i verifikationen, om at gennemgå de foreslåede kriterier. Personen kan opdage manglende startbetingelser eller et resultat, der ikke kan observeres med den tilgængelige testopsætning.

Verificer efter implementering hvert resultat, og registrer dokumentation gennem teamets normale Jira- eller dokumentationsproces. Vælg et punkts Done-knap, når det aftalte resultat er bestået. Et nyt valg sætter det tilbage til at gøre, hvis en senere opdagelse genåbner kontrollen.

For eksempel kan indstillingen overleve en genindlæsning af siden, men blive nulstillet efter et nyt login. Kriteriet om genåbning kan bestå, mens kriteriet om bevarelse mellem sessioner forbliver uafsluttet. Separate punkter bevarer den nyttige forskel.

Power Pack følger tjeklistens færdiggørelse; det udfører ikke testene og fastslår ikke automatisk, hvem der gennemgik dem. Hvis review kræver navngiven verifikation eller et dateret resultat, skal oplysningerne registreres udtrykkeligt i jeres normale proces.

Brug begge optællinger uden at forveksle dem med bevis

Acceptance Criteria og Definition of Done viser hver deres antal færdige og samlede punkter. Parathedsindikatoren viser kun Ready for Release, når begge lister er udfyldt, og hvert punkt i begge er færdigt. Ellers vises In Verification.

Det er en opsummering af den indtastede tjeklistestatus. Den kan ikke fastslå, at kriterierne dækker al vigtig adfærd, eller at dokumentationen er solid. Den håndhæver heller ikke Jira-overgange og blokerer ikke sammenfletninger.

Vores notifikationssag kan have alle otte acceptkriterier færdige, mens supportvejledningen stadig er ufærdig i Definition of Done. Funktionens resultater er bestået, men teamets bredere færdiggørelsesaftale har stadig et åbent punkt.

Start med én kommende Jira-sag. Skriv kunderesultatet, aftal de vigtige betingelser og resultater, og tilføj kriterierne i Power Pack sammen med den fælles Definition of Done. Gennemgå listen med dem, der skal bygge og verificere ændringen. Gevinsten er færre antagelser gemt bag en sætning, der i starten lød indlysende.

• Atlassian — Hvad er acceptkriterier?