Så skriver du utmärkta acceptanskriterier (med exempel)
Hur många gånger har du sett utvecklare och testare argumentera om hur en viss funktion borde fungera? Och hur är det med de förvirrade ansiktena hos utvecklare som inte var säkra på hur de skulle bygga funktionen du hade begärt? Båda är ganska vanliga problem inom programvaruvärlden och som tur är har du ett kraftfullt verktyg i din arsenal för att lösa dem – acceptanskriterier.
I den här guiden går jag igenom vad detta format för att dokumentera krav innebär, förklarar vilken roll det spelar inom produktledning och visar hur du skriver bra acceptanskriterier.
Innehållsförteckning
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Vad är syftet med att skriva acceptanskriterier?
Hur bör välskrivna acceptanskriterier se ut?
Vanliga format för acceptanskriterier
Vad är acceptanskriterier
(och var passar de in inom Agile/Scrum?)
Inom Agile-metodiken är ett acceptanskriterium den minsta enheten av ett funktionellt krav eller designkrav som agila produktchefer (eller verksamhetsanalytiker) lägger till i sina berättelser för att tydligt kommunicera de olika tillstånden och beteendena hos de funktioner som teamet planerar att bygga.
Tekniskt sett kan du använda acceptanskriterier var du vill. Traditionellt är de dock en del av användarberättelser, som är komponenter i agila epics.
För att förstå acceptanskriterier bättre ska vi först fräscha upp minnet och gå igenom elementen i denna hierarki samt se vad vart och ett används till.
Epics
Epics är uppgifter som innehåller funktionella och icke-funktionella krav på hög nivå för en stor funktion eller en grupp funktioner som är relaterade till varandra. Vanligtvis täcker en epic ett helt användningsfall för dina kunder och innehåller alla underliggande funktioner och all funktionalitet som du behöver implementera för att täcka det aktuella användningsfallet.
Föreställ dig att du var en del av produktteamet på Spotify och ville utöka användningen av appen genom att lägga till ett nytt användningsfall för personer som är på språng och inte har tillgång till internet.
För att täcka detta användningsfall kan du överväga att lägga till en ny stor funktion som kallas ”offline-läge för Spotify”, och den kan bli en epic i din produktbacklogg som innehåller alla övergripande krav för att låta användarna lyssna på musik utan internetanslutning, samt flera användarberättelser med kraven för specifika delar av denna funktion.
Användarberättelser
Användarberättelser är mindre till omfånget och representerar en enskild, avgränsad funktion inom epicsen. De är små arbetsdelar som Agile-teamet kan åta sig att leverera inom en enda iteration.
En av de viktigaste egenskaperna hos en användarberättelse är att funktionaliteten den representerar ska vara komplett och potentiellt användbar.
Om du till exempel bygger en app för lagring av filer online och vill låta användarna byta namn på filer som de har laddat upp, behöver du utföra arbete i frontend (användargränssnittet och användarupplevelsen för namnbyte) och i backend (lagringen av det nya namnet).
För att funktionen ska vara komplett och användbar behöver du slutföra båda uppgifterna och koppla ihop delarna i frontend och backend. Ditt team skulle göra allt detta inom ramen för en enda användarberättelse.
Om du bara skulle utföra backend-arbetet skulle uppgiften inte vara en riktig berättelse, eftersom den skulle innehålla en leverans som inte är komplett och användbar.
För att låta utvecklingsteamet veta hur funktionen kommer att se ut och hur den ska fungera skriver produktägare acceptanskriterier för berättelsen.
Acceptanskriterier för användarberättelser
Slutligen har vi de minsta delarna i hierarkin för krav på programvaruprodukter – acceptanskriterier. De representerar enskilda användningsscenarier för funktionaliteten eller informationsdelar som utvecklingsteamet kommer att anse vara viktiga när berättelsen implementeras.
I exemplet ovan skulle ett acceptanskriterium vara att öppna ett textfält med filens namn förifyllt om användaren klickar på knappen ✏️Byt namn på filen som de har laddat upp.
Definition av klar (ja, den skiljer sig från acceptanskriterier!)
Ibland blandar produktägare (särskilt de som är relativt nya i denna Scrum-roll) ihop definitionen av klar med acceptanskriterier.
Ärligt talat var det ganska förvirrande för mig i början också, eftersom båda är ”kriterier för att kontrollera om funktionen är komplett”.
Den enda skillnaden är att definitionen av när arbetet är klart representerar fullständighet utifrån teamets utvecklingsprocesser.
Medan acceptanskriterierna representerar funktionella krav (hur funktionen ska se ut och fungera).
Det innebär att definitionen av när arbetet är klart förblir densamma för alla berättelser som teamet implementerar, såvida de inte beslutar att ändra den under retrospektiven. Acceptanskriterierna är däremot unika för varje berättelse, eftersom de förklarar hur funktionen ska fungera.
Obs!: Vissa verktyg för produktledning låter dig ha både definitionen av när arbetet är klart och acceptanskriterier på dina berättelser.
Nu när vi minns vad epiker och berättelser handlar om, och hur acceptanskriterierna hänger ihop med dem, går vi vidare för att förstå varför produktägare över huvud taget skriver acceptanskriterier.
Vad är syftet med att skriva acceptanskriterier?
Kan jag inte bara skriva en beskrivning av en användarberättelse på det sätt jag vill utan att inkludera några acceptanskriterier? Vad är egentligen fördelen med att skriva acceptanskriterier?
Självklart kan du skriva dina berättelser på det sätt du vill. Jag rekommenderar dock att du använder acceptanskriterier som ett sätt att formulera dina krav, eftersom det här formatet har många fördelar. Här är ett par som du kan överväga.
De uppmuntrar till beteendedrivet tänkande
Om du väljer BDD-formatet för acceptanskriterier (mer om det senare), kommer dina acceptanskriterier att beskriva dina kunders resa när de använder den aktuella funktionen.
Det fina med det här tillvägagångssättet är att du flyttar ditt tänkande bort från torra tekniska krav och börjar betrakta funktionen ur användarens perspektiv. På så sätt kan du föreställa dig vad de upplever och känner när de interagerar med din funktion.
Det är mycket vanligt att produktägaren inser att den funktionalitet de har föreställt sig inte är den bästa när de betraktar den ur användarnas perspektiv.
Jag har själv upplevt det vid flera tillfällen. När jag till exempel tog fram krav för en redigerare av matematiska formler (den var en del av en SaaS-produkt för finansiell analys som vi utvecklade vid den tiden), ville jag att redigeringsprocessen skulle se ut så här:
- En redigeringsknapp bredvid formeln.
- Om man klickade på redigeringsknappen skulle formelfältet bli redigerbart och visa knapparna ✅ Spara och ❎ Avbryt .
- Om man klickade på någon av dem skulle redigeringsläget avslutas och antingen den nya, sparade versionen eller den gamla versionen av formeln visas där, beroende på användarens val.
Det här beteendet verkar logiskt, eller hur?
Jo, men inte förrän jag började skriva ner scenarier för analytiker som använde den och upptäckte ett betydande användbarhetsproblem. Analytiker brukar vanligtvis experimentera med formeln genom att göra små ändringar i den och titta på beräkningsresultatet tills de får den formel de vill ha.
Det sätt jag hade föreställt mig att redigeringen skulle fungera på skulle vara extremt irriterande för mina målgruppsanvändare, eftersom de skulle behöva gå in i och ut ur redigeringsläget 20–30 gånger i rad. Så snart jag insåg misstaget ändrade jag därför snabbt acceptanskriterierna och bad om att en formelredigerare skulle byggas där man kunde göra ändringar i realtid.
De bidrar till att skapa en enda sanningskälla
Som produktchef i början av min karriär var min största utmaning att kommunicera produktkrav till personer med olika yrkesroller eller till och med till olika team. Problemet var att var och en av dem tolkade kraven på olika sätt och kommunikationen mellan dem blev en otydlig röra.
Det var då en erfaren produktchef föreslog att jag skulle tillämpa konceptet med en enda sanningskälla genom att formulera mina produktkrav på ett mycket tydligt sätt (detta är något som AI vid kravinsamling kan hjälpa till med), kommunicera dem till alla och be dem att endast basera sitt arbete på det som stod där.
Det blev en enorm framgång, eftersom alla hade samma förståelse för hur funktionen skulle fungera, och om det uppstod meningsskiljaktigheter kunde de hänvisa tillbaka till kravet.
Acceptanskriterier är ett utmärkt sätt att skapa en enda källa till sanning, eftersom de beskriver funktionen på ett tydligt och lättläst sätt och har hög detaljnivå (eftersom de bör täcka alla viktiga detaljer i funktionen).
De förbättrar kvaliteten på acceptanstesterna
För programvaruingenjörer fungerar acceptanskriterier som produktkrav som de följer när de bygger funktionen. För ditt kvalitetsteam har acceptanskriterier däremot ett par ytterligare funktioner:
De hjälper till att prioritera testfall. Om ditt programvarutestteam har många testfall för funktionen och det inte finns tillräckligt med tid för att gå igenom alla, kommer de först att prioritera och köra de testscenarier som motsvarar acceptanskriterierna, eftersom dessa beskriver de mest kritiska användarflödena.
De fungerar som en checklista för godkännande. Denna punkt gäller både QA-team och produktägare som behöver godkänna funktionen. Acceptanskriterier fungerar, precis som namnet antyder, som en checklista för att avgöra om funktionen ska godkännas eller underkännas. Om ett eller flera av acceptanskriterierna inte uppfylls kommer QA-teamet att öppna ärendet igen och be teknikteamet att lägga till den saknade funktionaliteten.
Sammanfattningsvis är acceptanskriterier ovärderliga verktyg för produktägare när de ska kommunicera produktkrav på rätt sätt. Men hur skriver man bra acceptanskriterier? Låt mig hjälpa dig med det härnäst.
Hur bör välskrivna acceptanskriterier se ut?
Kvaliteten på de acceptanskriterier du skriver kommer att ha en direkt påverkan på kvaliteten hos de funktioner som ditt team levererar. Med en tydlig förståelse för vad som ska byggas och hur det ska testas kommer ditt team att bygga funktionen på det sätt du föreställt dig, med minimalt antal problem.
För att lyckas skriva acceptanskriterier behöver du uppmärksamma följande.
Tydlighet
Den första dödssynden som en produktägare kan begå är att skriva otydliga och vaga acceptanskriterier. Du kan glömma föreställningen om en gemensam förståelse om människor kan tolka det du har skrivit på flera olika sätt.
För att se hur stor skillnad det gör ska jag visa dig ett exempel.
Vad förstod du av den här meningen? Kan du säga hur ATM:en kommer att använda korttypen för att avgöra om användaren ska autentiseras eller inte? Kommer ATM:en att autentisera användaren om alla dessa kriterier är uppfyllda samtidigt, eller räcker det att bara ett av dem är uppfyllt?
Om du ger detta acceptanskriterium till dina ingenjörer kommer de att överösa dig med frågor och be dig att vara tydligare med dina krav. Låt oss nu göra det bättre.
Ser mycket bättre ut, eller hur? Med detta acceptanskriterium gav vi också svaren på alla ovanstående frågor. ATM:en behöver stödja den korttyp som användaren har satt in, och alla tre kriterier ska vara uppfyllda samtidigt för att ATM:en ska genomföra autentiseringen.
Proffstips: Gör dina acceptanskriterier SMARTA (specifika, mätbara, uppnåeliga, relevanta och testbara). Ja, jag har ändrat det sista till testbart, eftersom det är en viktig egenskap hos effektiva acceptanskriterier.
Läsbarhet
Förutom att undvika vaghet i dina acceptanskriterier bör du också hålla dem enkla och undvika onödigt avancerade termer eller komplicerad engelska.
Jag är säker på att du har ett team av högutbildade stjärnor som enkelt kan läsa och förstå de mest avancerade och komplexa orden och uttrycken i det engelska språket, men du vill egentligen inte slösa deras tankekraft på att tolka dina texter.
Så i stället för detta.
Säg detta.
Jag antar att du inte ens brydde dig om att läsa det första acceptanskriteriet helt, eftersom du inte heller ville slösa din tid och tankekraft!
Täckning av fallen
Djävulen finns i detaljerna. Ibland inser man att man har missat ett besvärligt fall i sin funktion när man har kommit väldigt långt i utvecklingsfasen och måste öppna en uppföljande förbättringsuppgift för det, eller till och med göra om alltihop.
Låter det bekant?
Ju fler fall du tar hänsyn till i dina acceptanskriterier från början, desto mindre är risken att du ställs inför det scenariot med dina uppgifter i ärendekön.
Nu tittar vi på acceptanskriterierna nedan.
Ser du något märkligt här? Vid första anblicken är kravet tydligt: du lägger till e-postadressen, trycker på skicka och personen får åtkomst. I verkligheten har vi inte tagit hänsyn till många fall här:
- Om e-postadressen redan finns i listan över användare som har åtkomst till dokumentet bör du kanske visa ett felmeddelande som informerar användaren om det.
- Du skickar ett inbjudningsmeddelande till användaren, så det kan därför vara värt att visa om personen har accepterat inbjudan eller inte i den delade listan.
- Om personen inte har accepterat inbjudan kan det kanske vara värt att lägga till en knapp för att skicka om inbjudan.
Det finns också negativa fall där du förtydligar hur funktionen ska bete sig när något är tomt eller ett fel har inträffat.
Aktiv användning av visuella hjälpmedel
Var acceptanskriterierna som jag delade ovan helt tydliga för dig? När jag pratade om fältet ”Lägg till personer och grupper”, förstod du tydligt vad det handlade om?
Ibland räcker inte ord för att ge ditt team klarhet kring kraven, och då är det bättre att visa dem än att berätta om dem. Låt mig nu förbättra de här acceptanskriterierna lite.
Har jag rätt i att anta att du enkelt skulle ha förstått vad jag pratade om med de här acceptanskriterierna om du såg bilden och mina kommentarer sida vid sida? Jag slår vad om att du skulle ha gjort det.
Det täcker alltså ”acceptanskriterierna” för acceptanskriterier – nu ska vi diskutera de olika typer och format som produktteam använder för dem.
Vanliga format för acceptanskriterier
Jag måste vara uppriktig med dig. Jag använder sällan samma format i alla mina användarberättelser. Anledningen är att olika format för acceptanskriterier passar bra för olika användningsfall, och det är inte alltid den bästa idén att tvinga sig själv att alltid använda samma format.
Därför väljer jag format utifrån berättelsen och vilken typ av information jag vill skriva i dess acceptanskriterier.
Nu tittar vi på några av de vanligaste formaten och deras motsvarande exempel på acceptanskriterier.
BDD-format
BDD står för beteendedriven utveckling (beteendedriven utveckling) och är ett ramverk som uppmuntrar medlemmar i programvaruutvecklings- och produktteam att definiera krav utifrån hur slutanvändarna kommer att interagera med funktionen.
Som ett sätt att skriva krav baserat på användarbeteende följer acceptanskriterierna för BDD den här specifika mallen:
Givet: Förvillkoret för det specifika scenariot av användarbeteende.
När: Den åtgärd som användaren utför.
Då: Resultatet av åtgärden.
Om du ville förklara hur uttagsfunktionen i en bankomat fungerar skulle dina acceptanskriterier alltså se ut så här:
Den här typen av acceptanskriterier med givet/när/då är utmärkt när du vill skapa empati för användarnas behov inom teamet genom att lägga tonvikten på användarens perspektiv.
More Articles
Checklisteformat
Till skillnad från BDD (även kallat ett ”scenariobaserat” format) visar det här formatet inte slutanvändarens perspektiv. I stället handlar det mer om att förklara de specifika regler som funktionens affärslogik ska följa (det alternativa namnet för det här formatet är ”regelbaserat”). Så här ser de ut.
Det här formatet passar bäst när logiken som du vill förklara är komplex, eftersom det hjälper dig att dela upp den i flera små regler som är enklare att förstå och implementera.
Flödesformat
Det här är förmodligen det format som jag använder mest.
Flödesformatet liknar BDD-formatet eftersom det också visar användarens perspektiv. Till skillnad från BDD kräver det dock inte en strikt struktur (Given/When/Then). Därför kan du fritt beskriva stegen som användaren tar på det sätt du vill.
Så här skulle registreringsprocessen se ut med det här formatet.
Flödesformatet är det bästa alternativet om du vill skapa förståelse för användaren (precis som med BDD), men inte riktigt vill följa en strikt struktur.
Håll alla på samma sida med acceptanskriterier
Acceptanskriterier är kraftfulla verktyg i händerna på produktägare, eftersom de kan skapa en enda källa till sanning och hålla sina teammedlemmar samordnade kring sin vision för den funktionen.
För fler guider som denna och andra bra resurser för produktpersoner kan du prenumerera på vårt nyhetsbrev!
