Användarberättelse är en teknik som gör det möjligt för företag att leverera produkter och tjänster som möter kundens behov maximalt. Acceptanskriterier för användarberättelser förbättrar bedömningen av nya produktfunktioner ur användarens perspektiv.
Acceptanskriterier för användarberättelser – innehållsförteckning:
- Introduktion
- Hur formulerar man acceptanskriterier för användarberättelser?
- Acceptanskriterier för användarberättelser vs. Definition av klart
- Sammanfattning
Introduktion
Vi har täckt användarberättelse och frågor att ta itu med vid dess skapande i tidigare artiklar. Idag kommer vi dock att fokusera på acceptanskriterier för användarberättelser.
Acceptanskriterierna bör följa dessa riktlinjer:
- beskriva den nya och förbättrade funktionaliteten av produkten ur användarens perspektiv
- vara unika för varje användarberättelse
Den officiella Scrum-guiden definierar inte användarberättelse och dess acceptanskriterier. De är valfria, men mycket vanliga element i Scrum-arbete. Ändå, för att stilla våra läsares nyfikenhet, kommer vi att beskriva dem som: De villkor som en produktförbättring måste uppfylla under en given sprint för att få godkännande från användaren.

Hur formulerar man acceptanskriterier för användarberättelser?
En välskriven användarberättelse innehåller en tydlig beskrivning av den kontext eller situation den berör, vilket uppfyller acceptanskriterierna. Ändå är det bara en kort mening, för vag och tvetydig för att direkt peka ut nödvändiga överväganden.
Tydlighet och tillgänglighet av acceptanskriterier
Därför, för att förhindra tvetydigheter, genomför och dokumentera en detaljerad konversation med kunden för att fastställa syftet med den implementerade lösningen. Kom ihåg att den slutliga formuleringen av acceptanskriterier tillhör produktägaren.
Skriv ner dem tillsammans med kriterierna för användarberättelsen innan sprintplaneringen. Varje medlem i Scrum-teamet måste läsa dem och bekräfta att de förstår och håller med om acceptanskriterierna för användarberättelsen. Vanligtvis finns acceptanskriterierna på den andra sidan av användarberättelsens kort.
Välformulerade acceptanskriterier gör det möjligt för användaren att kontrollera om testningen av användarberättelsen följer dess beskrivning. Kriterierna kan ta formen av en checklista med punkter att bocka av när de är slutförda under produktens testning i slutet av en sprint.
Frågan är enkel om produktens funktion är transparent för användaren. Ju mer komplex produkten är, desto svårare blir det att testa. Ta komplex mjukvara eller storskaliga tjänster. Därför är det i de flesta fall ett användbart verktyg att validera användarberättelsen genom att förbereda ett acceptanstest.
Acceptanstest
Om du beslutar att utveckla ett acceptanstest, skriv ner det på den andra sidan av kortet som innehåller användarberättelsen. Senare kan Scrum-teamet eller ett externt QA-team genomföra det.
Testet måste framför allt innehålla ett tydligt uttalande om huruvida produkten misslyckas eller klarar testet. Det får inte innehålla procentuella uttalanden eller mellanliggande utvärderingar.
Om användarberättelsen har mer än ett acceptanskriterium, kräver varje separat testning. På så sätt är det mycket lättare att avgöra vilken produktfunktionalitet som behöver förbättras eller förfinas, och det är särskilt viktigt om nya funktioner som ingår i användarberättelsen överlappar eller är oberoende av varandra.

Acceptanskriterier för användarberättelser vs. Definition av klart
Definition av klart är en integrerad del av att arbeta i Scrum, vilket är den tekniska motsvarigheten till acceptanskriterier. Du bör dock inte förväxla dessa två, eftersom de betecknar olika åtaganden. Vad är definitionen av klart, och hur och när man formulerar den är en fråga vi har täckt i ett separat inlägg?
Här kommer vi bara att nämna att definitionen av klart är en tydlig och transparent beskrivning av det förväntade tillståndet för produkten efter slutförandet av inkrementet i produktbackloggen. Den beskriver de förbättringar som gjorts inom inkrementet. Detta står i kontrast till acceptanskriteriet som motsvarar användarberättelsen, vilket beskriver produktens funktionalitet som skapades under den senaste sprinten, så som den uppfattas av kunden.
Till exempel, ta denna användarberättelse med innehållet:
Som en inloggad kund i en nätbutik vill jag köpa en magisk stav med ett klick.
Definitionen av klart för ovanstående användarberättelse kan inkludera följande:
- skapandet av en inloggningspanel för butikens kunder
- integration av betalningssystemet
- tillägg av knappen för omedelbar betalning till produktens sidmall
Å andra sidan innehåller kundens acceptanskriterier:
- möjligheten att logga in i butiken
- möjligheten att definiera en standardbetalningsmetod
- en fungerande “Köp nu”-knapp för produkten “magisk stav”
Sammanfattning
Acceptanskriterierna är en uppsättning villkor som fungerar som ett sätt att utvärdera genomförandet av användarberättelsen. Genom att beskriva ny och förbättrad produktprestanda ur användarens perspektiv blir denna metod ett effektivt verktyg för att arbeta med kunden. Den presenterar Scrum-teamets prestationer ur användarens synvinkel.
Välformulerade acceptanskriterier, till exempel i form av ett acceptanstest, gör det också möjligt för oss att kontrollera under en sprint om den skapade funktionaliteten förbättrar mötet med kundens krav.
Acceptanskriterier skiljer sig från definitionen av klart främst i den perspektiv de tar vid uttryck. De innehåller inte en beskrivning av tekniska krav som den nya lösningen bör uppfylla, utan endast de funktioner som produkten bör ha efter att den nya användarberättelsen har realiserats.
Om du gillar vårt innehåll, gå med i vår aktiva gemenskap av flitiga bin på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Som projektledare är Caroline en expert på att hitta nya metoder för att utforma de bästa arbetsflödena och optimera processer. Hennes organisatoriska färdigheter och förmåga att arbeta under tidspress gör henne till den bästa personen att förvandla komplicerade projekt till verklighet.
Scrum Guide:
- Ordlista över grundläggande termer, roller och begrepp
- Vad är Scrum?
- Scrum-värden
- Hur implementerar man Scrum i ditt företag?
- Scrum-team - vad är det och hur fungerar det?
- Vem är en produktägare?
- De vanligaste misstagen hos en produktägare
- Vem är Scrum Master?
- De vanligaste misstagen av Scrum Master
- Vilka statistik och mätvärden bör Scrum Mastern följa?
- Utvecklingsteam i Scrum
- De vanligaste misstagen hos utvecklare
- Scrumartefakter
- Skalning av Scrum
- Sprint Backlog
- Vad är produktbackloggen?
- Vad är användarberättelser?
- Skapa den bästa användarberättelsen med INVEST
- De vanligaste misstagen i User Stories
- Användarberättelse Acceptanskriterier
- Uppskattning och Story Points i Scrum
- Planeringspoker
- Team Estimation Game
- Definiera inkrement
- Scrum-evenemang
- Vad är en Burndown-diagram?
- Fördelar och nackdelar med burndown-diagrammet
- Kanban-tavlor i Scrum och Scrumban
- Hastighet i Scrum - Utvecklingsteamets hastighet
- Daglig Scrum
- Sprintplanering
- Sprintgranskning
- Vad är en Sprint Retrospektiv?
- Vanliga misstag under en Sprint Retrospektiv
- Produktbacklogg vård
- Hur man skapar och tolkar ett burndown-diagram?
- Vad är Sprint i Scrum?
- Samarbete mellan Produktägare och Scrum Master
- Scrumteamets åtaganden - Produktmål, Sprintmål och Definition av klarhet
- Egenskaper hos en bra Scrum Master