Slik skriver du akseptansekriterier i Jira – med praktiske eksempler

«Kunder kan endre varslingsinnstillingene sine» høres ut som en tydelig Jira-sak til noen begynner å bygge den. Lagres endringen umiddelbart? Hva skjer hvis lagring feiler? Er innstillingen der i morgen? Hvilke e-poster påvirkes?

Akseptansekriterier gjør åpne spørsmål til avtalte, observerbare resultater. De hjelper dem som bestiller, bygger og vurderer en endring med å jobbe ut fra de samme forventningene.

I denne veiledningen utvikler vi kriterier for en fiktiv kundeportalfunksjon, forbedrer uklare krav og legger en praktisk sjekkliste til Power Packs Definition of Done & AC-verktøy. Du trenger ikke et spesielt skriveformat for å begynne. Tydelige betingelser og resultater er nok.

Hva er akseptansekriterier?

Akseptansekriterier beskriver betingelsene et bestemt arbeid må oppfylle for å bli akseptert. De fokuserer på forventet resultat av dette arbeidet. Atlassian skiller dem fra Definition of Done, som beskriver den bredere kvalitetsstandarden for fullført arbeid. Se Atlassians veiledning om akseptansekriterier.

I eksemplet er «Et lagret varslingsvalg forblir valgt etter at kunden logger inn igjen» et akseptansekriterium. «Implementeringen er gjennomgått» hører hjemme i den felles Definition of Done.

Skillet holder begge listene nyttige. Akseptansekriteriene forklarer om funksjonen gjør det teamet avtalte. Definition of Done forklarer om arbeidet oppfyller teamets bredere ferdigstandard.

Ingen av listene trenger å inneholde hvert implementeringstrinn. «Opprett et databasefelt» kan være en nødvendig utviklingsoppgave, men forteller ikke en kunde eller kontrollør om innstillingen oppfører seg riktig.

Start med ett kunderesultat

Den fiktive saken heter «La kunder styre den ukentlige oppsummeringsmailen». Målet er at en innlogget kunde kan velge om de mottar en ukentlig oppsummering uten å endre viktige kontomeldinger.

Før kriteriene skrives, avtaler teamet noen omfangsbeslutninger. Innstillingen har en eksplisitt Save-knapp. Kunden endrer bare sin egen innstilling. Innstillingen gjelder oppsummeringer som ennå ikke er lagt i kø. Meldinger som allerede er i kø, er utenfor leveringsregelen til denne saken.

Detaljene er oppdiktet for eksemplet. Teamet bør avgjøre sin faktiske atferd fremfor å kopiere dem som produktkrav.

Et kort omfangsnotat kan forhindre at en lang sjekkliste må bære all konteksten. I Jira-beskrivelsen registrerer teamet at saken gjelder én innstilling på kontoinnstillingssiden. Valg av leveringsdager, endring av e-postadresser og administrering av andre kunders innstillinger er separat arbeid.

Nå kan kriteriene fokusere på resultatene som viser om denne bestemte endringen fungerer.

Skriv normalforløpet først

Start med opplevelsen du forventer at de fleste kunder følger. Beskriv startbetingelsen, handlingen og det observerbare resultatet med vanlig språk.

For eksempel: «Når en innlogget kunde slår av ukentlige oppsummeringer og lagrer vellykket, viser kontoinnstillingene oppsummeringer som avslått når de åpnes igjen.» En kontrollør kan opprette starttilstanden, utføre handlingen og undersøke resultatet.

Setningen er mer nyttig enn «Innstillinger lagres riktig». Den sier hvilken innstilling som endres, når endringen gjelder, og hvordan den kan kontrolleres.

Teamet trenger også motsatt retning. En kontroll som kan slå av oppsummeringer, men ikke slå dem på, er ufullstendig. Skriv et separat kriterium når den motsatte atferden trenger egen verifisering.

Ikke press urelaterte resultater inn i ett punkt. Lagring, tastaturbruk, e-postlevering og feilhåndtering kan alle være viktige, men ett enormt kriterium gjør det vanskelig å vise hvilken del som fortsatt trenger oppmerksomhet.

Legg til feil- og grensetilfeller

Normalforløpet antar at lagring lykkes. Spør hva kunden skal se når antakelsen ikke stemmer.

Teamet velger denne regelen: hvis lagringsforespørselen feiler, viser siden en feil og ingen suksessbekreftelse. Når siden åpnes igjen, står den tidligere lagrede innstillingen igjen. Det gir kontrolløren et konkret feiltilfelle å prøve i teamets testmiljø.

Undersøk så funksjonens grense. Innstillingen for ukentlig oppsummering må ikke stoppe en e-post for tilbakestilling av passord. Kundens valg må også overleve en ny innloggingsøkt. Dette er ulike hensyn og får separate kriterier.

Unngå «Alle grensetilfeller håndtert». Angi tilfellene som er viktige. En nyttig diskusjon starter ofte med tre spørsmål: hva kan feile, hva må være upåvirket, og hva skjer senere?

Hvis teamet ikke kan avtale et forventet resultat, registrer den åpne beslutningen før implementeringen kommer for langt. Et ubesvart spørsmål blir ikke et brukbart kriterium bare fordi det står i en sjekkliste.

En gjennomarbeidet sjekkliste med akseptansekriterier

Her er første komplette utkast for den fiktive saken. Hvert punkt beskriver et resultat teamet kan verifisere separat.

• Åpning av kontoinnstillinger viser kundens nåværende lagrede valg for ukentlig oppsummering.
• Etter å ha slått av ukentlige oppsummeringer og lagret vellykket, viser gjenåpning av kontoinnstillinger innstillingen som av.
• Etter å ha slått på ukentlige oppsummeringer og lagret vellykket, viser gjenåpning av kontoinnstillinger innstillingen som på.
• Etter vellykket lagring bevares innstillingen ved utlogging og ny innlogging.
• Hvis lagring feiler, vises en feil, ingen suksessbekreftelse vises, og gjenåpning viser den tidligere lagrede innstillingen.
• En kunde med innstillingen av mottar ingen ukentlig oppsummering som legges i kø etter vellykket lagring.
• En kunde med innstillingen på er fortsatt kvalifisert for neste ukentlige oppsummering etter eksisterende planleggingsregler.
• Å slå av ukentlige oppsummeringer hindrer ikke kunden i å motta en forespurt e-post for tilbakestilling av passord.

Leveringspunktene avhenger av omfangsbeslutningen om meldinger i kø. Teamet registrerer konteksten ved siden av saken, slik at kontrolløren ikke antar at innstillingen trekker tilbake e-poster som allerede sendes.

Kriteriene trenger også en praktisk verifiseringsmetode. For leveringsatferden identifiserer teamet hvordan en oppsummering kan utløses eller observeres i testmiljøet. Et kriterium kan være tydelig skrevet og likevel vanskelig å kontrollere hvis ingen har tilgang til nødvendig konto eller leveringsdokumentasjon.

Forbedre uklare kriterier før de legges til

En rask gjennomgang av ordlyden forebygger ofte lengre uenigheter senere. Les hvert punkt og spør om to personer kan tolke suksess forskjellig.

Det siste eksemplet beviser ikke brukervennlighet alene. Det erstatter én uklar setning med én nyttig, begrenset kontroll. Bredere brukervennlighetsmål kan kreve undersøkelser eller flere avtalte observasjoner.

Vær også forsiktig med oppdiktet presisjon. Et krav om to sekunders responstid høres målbart ut, men skaper en reell forpliktelse. Avtal betingelsene og begrunnelsen for en ytelsesgrense før den tas med.

Legg kriteriene inn i Power Pack

Åpne Jira-saken og finn Definition of Done & AC-kortet. Velg Acceptance Criteria-fanen. Listen er separat fra Definition of Done, så kontroller valgt fane før du legger inn innhold.

For ett kriterium skriver du tittelen og velger Add eller trykker Enter. Bruk korte titler som fortsatt bevarer det forventede resultatet. Hvis et kriterium trenger omfattende kontekst, hold den i Jira-beskrivelsen eller teamets lenkede dokumentasjon.

For flere punkter velger du Bulk Import og limer inn en Markdown-punktliste. Du kan kopiere eksemplene ovenfor med bindestrek og mellomrom foran hvert punkt. Markdown-lister med avkrysningsbokser støttes også.

Gå gjennom punktene etter import. Handlingen legger til i den nåværende listen, så å importere samme sjekkliste igjen kan opprette eksisterende punkter på nytt. Avkryssede Markdown-punkter kommer som ferdige; start med uavkryssede punkter hvis ikke resultatene for den aktuelle saken faktisk er verifisert.

Hvis et punkt er feil, gå gjennom erstatningsteksten med teamet, legg til det korrigerte punktet og slett det gamle via bekreftelsen. Hold sakens støttende diskusjon tydelig når en endring påvirker avtalt omfang.

Vurder resultater før de merkes ferdige

Be før implementering en person som deltar i verifiseringen om å gå gjennom kriteriene. Personen kan oppdage manglende startbetingelser eller et resultat som ikke kan observeres med tilgjengelig testoppsett.

Verifiser hvert resultat etter implementering og registrer dokumentasjon gjennom teamets vanlige Jira- eller dokumentasjonsprosess. Velg punktets Done-knapp når avtalt resultat har bestått. Å velge den igjen setter punktet tilbake til ugjort hvis et senere funn gjenåpner kontrollen.

En innstilling kan for eksempel overleve sideoppdatering, men nullstilles etter ny innlogging. Kriteriet for gjenåpning av siden kan bestå mens kriteriet for bevaring mellom økter er uferdig. Separate punkter bevarer dette nyttige skillet.

Power Pack følger sjekklistens fullføring; det utfører ikke testene og fastslår ikke automatisk hvem som gjennomgikk dem. Hvis gjennomgangen krever navngitt verifisering eller et datert resultat, registrer detaljene uttrykkelig i vanlig prosess.

Bruk begge tallene uten å forveksle dem med bevis

Acceptance Criteria og Definition of Done viser hver sine ferdige og totale antall. Klarhetsindikatoren viser bare Ready for Release når begge listene er utfylt og hvert punkt i begge er ferdig. Ellers viser den In Verification.

Dette er en oppsummering av sjekklistestatusen som er lagt inn. Den kan ikke fastslå at kriteriene dekker all viktig atferd, eller at underlaget er godt. Den håndhever heller ikke Jira-overganger eller blokkerer sammenslåinger.

Varslingssaken kan ha alle åtte akseptansekriterier ferdige mens støtteveiledningen fortsatt er uferdig i Definition of Done. Funksjonsresultatene har bestått, men teamets bredere ferdigavtale har fortsatt et åpent punkt.

Start med én kommende Jira-sak. Skriv kunderesultatet, avtal viktige betingelser og resultater, og legg kriteriene til Power Pack sammen med felles Definition of Done. Gjennomgå listen med dem som skal bygge og verifisere endringen. Gevinsten er færre antakelser bak en setning som først virket åpenbar.

• Atlassian — Hva er akseptansekriterier?