Så skriver du acceptanskriterier i Jira – med praktiska exempel

”Kunder kan ändra sina aviseringsinställningar” låter som ett tydligt Jira-ärende tills någon börjar bygga det. Sparas en ändring direkt? Vad händer om sparandet misslyckas? Finns inställningen kvar i morgon? Vilka mejl påverkas?

Acceptanskriterier förvandlar öppna frågor till överenskomna, observerbara resultat. De hjälper personerna som beställer, bygger och granskar en ändring att arbeta utifrån samma förväntningar.

I den här guiden utvecklar vi kriterier för en fiktiv kundportalfunktion, förbättrar vaga krav och lägger till en praktisk checklista i Power Packs verktyg Definition of Done & AC. Du behöver inget särskilt skrivformat för att börja. Tydliga villkor och resultat räcker.

Vad är acceptanskriterier?

Acceptanskriterier beskriver villkoren som ett visst arbete måste uppfylla för att accepteras. De fokuserar på det förväntade resultatet av just det arbetet. Atlassian skiljer dem från Definition of Done, som beskriver den bredare kvalitetsstandarden för färdigt arbete. Se Atlassians guide till acceptanskriterier.

I vårt exempel är ”Ett sparat aviseringsval är fortfarande markerat när kunden loggar in igen” ett acceptanskriterium. ”Implementationen har granskats” hör till den gemensamma Definition of Done.

Skillnaden håller båda listorna användbara. Acceptanskriterierna förklarar om funktionen gör vad teamet har kommit överens om. Definition of Done förklarar om arbetet uppfyller teamets bredare färdigstandard.

Ingen av listorna behöver innehålla varje implementationssteg. ”Skapa ett databasfält” kan vara en nödvändig utvecklingsuppgift, men berättar inte för en kund eller granskare om inställningen beter sig rätt.

Börja med ett kundresultat

Vårt fiktiva ärende heter ”Låt kunder styra veckosammanfattningsmejlet”. Det avsedda resultatet är att en inloggad kund kan välja om den vill få en veckosammanfattning utan att ändra viktiga kontomeddelanden.

Innan teamet skriver kriterier kommer det överens om några omfattningsbeslut. Inställningen har en uttrycklig Save-knapp. Kunden ändrar bara sin egen inställning. Inställningen påverkar sammanfattningar som ännu inte har köats. Redan köade meddelanden ligger utanför ärendets leveransregel.

Detaljerna är påhittade för exemplet. Ditt team bör bestämma sitt faktiska beteende i stället för att kopiera dem som produktkrav.

En kort omfattningsnotering kan hindra en lång checklista från att behöva bära allt sammanhang. I Jira-beskrivningen dokumenterar teamet att ärendet omfattar en inställning på sidan för kontoinställningar. Val av leveransdagar, ändring av mejladresser och hantering av andra kunders inställningar är separat arbete.

Nu kan kriterierna fokusera på resultaten som visar om just denna ändring fungerar.

Skriv normalfallet först

Börja med upplevelsen du förväntar dig att de flesta kunder följer. Beskriv utgångsläget, handlingen och det observerbara resultatet med vanligt språk.

Till exempel: ”När en inloggad kund stänger av veckosammanfattningar och sparar framgångsrikt visar kontoinställningarna veckosammanfattningar som avstängda när sidan öppnas igen.” En granskare kan skapa utgångsläget, utföra handlingen och inspektera resultatet.

Meningen är mer användbar än ”Inställningarna sparas korrekt”. Den anger vilken inställning som ändras, när ändringen träder i kraft och hur den kan kontrolleras.

Teamet behöver också motsatt riktning. Ett reglage som stänger av sammanfattningar men inte kan slå på dem är ofullständigt. Skriv ett separat kriterium när det omvända beteendet förtjänar egen verifiering.

Pressa inte in orelaterade resultat i en enda punkt. Sparande, tangentbordsanvändning, mejlleverans och felhantering kan alla spela roll, men ett enormt kriterium gör det svårt att visa vilken del som fortfarande behöver uppmärksamhet.

Lägg till felfall och gränsfall

Normalfallet förutsätter att sparandet lyckas. Fråga vad kunden ska se när antagandet inte stämmer.

Vårt team väljer följande regel: om sparbegäran misslyckas visar sidan ett fel och ingen framgångsbekräftelse. När sidan öppnas igen finns den tidigare sparade inställningen kvar. Det ger granskaren ett konkret felfall att prova i teamets testmiljö.

Granska sedan funktionens gräns. Inställningen för veckosammanfattningar får inte stoppa ett mejl för lösenordsåterställning. Kundens val måste också överleva en ny inloggningssession. Det är olika frågor och därför får de separata kriterier.

Skriv inte ”Alla gränsfall hanterade”. Namnge fallen som spelar roll. Ett användbart samtal börjar ofta med tre frågor: vad kan misslyckas, vad måste förbli opåverkat och vad händer senare?

Om teamet inte kan enas om ett förväntat resultat, dokumentera det olösta beslutet innan implementationen går för långt. En obesvarad fråga blir inte ett användbart kriterium bara för att den står i en checklista.

En genomarbetad checklista med acceptanskriterier

Här är första fullständiga utkastet för det fiktiva ärendet. Varje punkt beskriver ett resultat som teamet kan verifiera separat.

• När kontoinställningarna öppnas visas kundens aktuella sparade inställning för veckosammanfattningar.
• När veckosammanfattningar stängs av och sparas framgångsrikt visas inställningen som avstängd när kontoinställningarna öppnas igen.
• När veckosammanfattningar slås på och sparas framgångsrikt visas inställningen som påslagen när kontoinställningarna öppnas igen.
• Efter en lyckad sparning bevaras inställningen vid utloggning och ny inloggning.
• Om sparandet misslyckas visas ett fel, ingen framgångsbekräftelse visas och när inställningarna öppnas igen visas det tidigare sparade valet.
• En kund vars inställning är av får ingen veckosammanfattning som nyköas efter den lyckade sparningen.
• En kund vars inställning är på förblir berättigad till nästa veckosammanfattning enligt befintliga schemaläggningsregler.
• Att stänga av veckosammanfattningar hindrar inte kunden från att få ett begärt mejl för lösenordsåterställning.

Leveranspunkterna beror på omfattningsbeslutet om köade meddelanden. Teamet dokumenterar sammanhanget intill ärendet så att granskaren inte antar att inställningen återkallar mejl som redan håller på att skickas.

Kriterierna behöver också ett fungerande verifieringssätt. För leveransbeteendet identifierar teamet hur en sammanfattning kan utlösas eller observeras i testmiljön. Ett kriterium kan vara tydligt skrivet men svårt att verifiera om ingen har tillgång till rätt konto eller leveransunderlag.

Förbättra vaga kriterier innan du lägger till dem

En snabb språkgranskning förebygger ofta längre oenigheter senare. Läs varje punkt och fråga om två personer kan tolka framgång olika.

Det sista exemplet bevisar inte användbarhet i sig. Det ersätter en vag mening med en användbar, begränsad kontroll. Bredare användbarhetsmål kan kräva undersökningar eller flera överenskomna observationer.

Var också försiktig med påhittad precision. Ett krav på två sekunders svarstid låter mätbart, men skapar ett verkligt åtagande. Kom överens om villkoren och skälet till en prestandagräns innan ni inkluderar den.

Lägg kriterierna i Power Pack

Öppna Jira-ärendet och hitta kortet Definition of Done & AC. Välj fliken Acceptance Criteria. Listan är skild från fliken Definition of Done, så kontrollera vald flik innan du skriver in innehållet.

För att lägga till ett kriterium skriver du titeln och väljer Add eller trycker på Enter. Använd korta titlar som ändå bevarar det förväntade resultatet. Om ett kriterium behöver mycket sammanhang, behåll det i Jira-beskrivningen eller teamets länkade dokumentation.

För flera punkter väljer du Bulk Import och klistrar in en Markdown-punktlista. Du kan kopiera exempelposterna ovan med bindestreck och mellanslag före varje punkt. Markdown-listor med kryssrutor stöds också.

Granska posterna efter importen. Åtgärden lägger till i den befintliga listan, så samma checklista igen kan skapa poster som redan finns. Markerade Markdown-kryssrutor läggs in som klara; börja med omarkerade poster om inte det aktuella ärendets resultat faktiskt har verifierats.

Om en post är felaktig, granska ersättningsformuleringen med teamet, lägg till den rättade posten och ta bort den gamla via bekräftelserutan. Håll ärendets stödjande diskussion tydlig när en ändring påverkar överenskommen omfattning.

Granska resultaten innan de markeras klara

Be före implementationen någon som deltar i verifieringen gå igenom de föreslagna kriterierna. Personen kan upptäcka saknade utgångsvillkor eller resultat som inte kan observeras med den tillgängliga testuppsättningen.

Verifiera varje resultat efter implementationen och dokumentera underlag genom teamets vanliga Jira- eller dokumentationsprocess. Välj en posts Done-knapp när det överenskomna resultatet har godkänts. Välj den igen för att återställa till att göra om en senare upptäckt öppnar kontrollen på nytt.

Inställningen kanske till exempel överlever en sidomladdning men återställs efter en ny inloggning. Kriteriet för att öppna sidan igen kan godkännas medan kriteriet för bevarande mellan sessioner är ofärdigt. Separata poster bevarar den användbara skillnaden.

Power Pack följer checklistans färdigställande; det utför inte testerna och fastställer inte automatiskt vem som granskade dem. Om granskningen kräver namngiven verifiering eller ett daterat resultat, dokumentera uppgifterna uttryckligen i er vanliga process.

Använd båda antalen utan att förväxla dem med bevis

Acceptance Criteria och Definition of Done visar var sitt antal klara och totala poster. Beredskapsindikatorn visar Ready for Release endast när båda listorna är ifyllda och varje post i båda är klar. Annars visas In Verification.

Det är en sammanfattning av den inmatade checklistestatusen. Den kan inte fastställa att kriterierna täcker alla viktiga beteenden eller att underlaget är tillförlitligt. Den upprätthåller inte heller Jira-övergångar och blockerar inte sammanslagningar.

Vårt aviseringsärende kan ha alla åtta acceptanskriterier klara medan supportvägledningen fortfarande är ofärdig i Definition of Done. Funktionsresultaten har godkänts, men teamets bredare överenskommelse om färdigställande har fortfarande en öppen punkt.

Börja med ett kommande Jira-ärende. Skriv kundresultatet, kom överens om viktiga villkor och resultat och lägg sedan kriterierna i Power Pack intill den gemensamma Definition of Done. Granska listan med dem som ska bygga och verifiera ändringen. Vinsten är färre antaganden gömda bakom en mening som först lät självklar.

• Atlassian — Vad är acceptanskriterier?