Brugerhistorie er en teknik, der gør det muligt for virksomheder at levere produkter og tjenester, der opfylder kundens behov maksimalt. Acceptkriterierne for Brugerhistorie forbedrer vurderingen af nye produktfunktionaliteter fra brugerens synspunkt.
Vi har dækket Brugerhistorie og de problemer, der skal tackles ved dens oprettelse i tidligere artikler. I dag vil vi dog fokusere på acceptkriterierne for Brugerhistorie.
Acceptkriterierne skal følge disse retningslinjer:
Den officielle Scrum Guide definerer ikke Brugerhistorie og dens acceptkriterier. De er valgfrie, men meget almindelige elementer i Scrum-arbejde. For at imødekomme vores læseres nysgerrighed vil vi dog beskrive dem som: De betingelser, som en produktforbedring skal opfylde i løbet af en given Sprint for at få godkendelse fra brugeren.
En veludført Brugerhistorie indeholder en klar beskrivelse af den kontekst eller situation, den vedrører, og opfylder dermed acceptkriterierne. Det er dog blot en kort sætning, for vag og tvetydig til at pege direkte på nødvendige overvejelser.
Derfor, for at forhindre tvetydigheder, skal der gennemføres og registreres en detaljeret samtale med kunden for at bestemme formålet med den implementerede løsning. Husk at den endelige formulering af acceptkriterier tilhører Product Owner.
Skriv dem ned sammen med kriterierne for Brugerhistorie før Sprint Planlægning. Hvert medlem af Scrum Teamet skal læse det og bekræfte, at de forstår og er enige i acceptkriterierne for Brugerhistorie. Normalt er acceptkriterierne på den anden side af Brugerhistoriekortet.
Ordentligt formulerede acceptkriterier giver brugeren mulighed for at kontrollere, om testningen af Brugerhistorie følger dens beskrivelse. Kriterierne kan tage form af en tjekliste med punkter til at krydse af, når de er gennemført under produkt testen ved slutningen af en Sprint.
Det er simpelt, hvis produktets funktion er gennemsigtig for brugeren. Jo mere komplekst produktet er, desto sværere bliver det at teste. Tag komplekse softwareløsninger eller storskala tjenester. Derfor er det i de fleste tilfælde et nyttigt værktøj at validere Brugerhistorie ved at forberede en accepttest.
Hvis du beslutter at udvikle en accepttest, skal du skrive den ned på den anden side af kortet, der indeholder Brugerhistorien. Senere kan Scrum Teamet eller et eksternt QA-team udføre den.
Testen skal først og fremmest indeholde en klar erklæring om, hvorvidt produktet fejler eller består testen. Den kan ikke indeholde procentangivelser eller mellem evalueringer.
Hvis Brugerhistorien har mere end ét acceptkriterium, kræver hver separat testning. På denne måde er det meget lettere at bestemme, hvilken produktfunktionalitet der har brug for forbedring eller forfining, og det er især vigtigt, hvis nye funktionaliteter, der er inkluderet i Brugerhistorien, overlapper eller er uafhængige af hinanden.
Definition af Færdig er en integreret del af arbejdet i Scrum, som er den tekniske ækvivalent af acceptkriterier. Du bør dog ikke forveksle disse to, da de angiver forskellige forpligtelser. Hvad er Definition af Færdig, og hvordan og hvornår man skal formulere den, er et emne, vi har dækket i et separat indlæg?
Her vil vi kun nævne, at Definition af Færdig er en klar og gennemsigtig beskrivelse af den forventede tilstand af produktet efter afslutningen af Inkrementet i produktbackloggen. Den beskriver de forbedringer, der er foretaget inden for Inkrementet. Dette står i kontrast til acceptkriteriet, der svarer til Brugerhistorien, som beskriver produktfunktionaliteten, der er skabt under den sidste Sprint, som den opfattes af kunden.
For eksempel, tag denne Brugerhistorie med indholdet:
Som en indlogget kunde i en online butik ønsker jeg at købe en tryllestav med ét klik.
Definitionen af Færdig for ovenstående Brugerhistorie kunne inkludere følgende:
På den anden side indeholder kundens acceptkriterier:
Acceptkriterierne er et sæt betingelser, der fungerer som en måde at evaluere implementeringen af Brugerhistorien. Ved at beskrive ny og forbedret produktpræstation fra brugerens synspunkt bliver denne metode et effektivt værktøj til at arbejde med kunden. Den præsenterer Scrum Teamets præstation fra brugerens synspunkt.
Velformulerede acceptkriterier, for eksempel i form af en accepttest, giver os også mulighed for at kontrollere under en Sprint, om den oprettede funktionalitet forbedrer opfyldelsen af kundens krav.
Acceptkriterier adskiller sig fra Definition af Færdig primært i den perspektiv, de tager ved udtryk. De indeholder ikke en beskrivelse af tekniske krav, som den nye løsning skal opfylde, men kun de funktioner, som produktet skal have efter realiseringen af den nye Brugerhistorie.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Som projektleder er Caroline en ekspert i at finde nye metoder til at designe de bedste arbejdsgange og optimere processer. Hendes organisatoriske færdigheder og evne til at arbejde under tidspres gør hende til den bedste person til at gøre komplicerede projekter til virkelighed.
Får du nogensinde følelsen af, at dagen er for kort til at gøre alt det,…
Hvad er software? Hvad er typerne og metoderne til distribution? Når vi holder os til…
At præsentere og kommunikere forskningsresultater er sandsynligvis en af de mest afgørende (og krævende) evner…
Ved du, hvordan man opretter en e-bog? Kender du alle de væsentlige aspekter af en…
Bæredygtig markedsføring er ikke længere bare en af de markedsføringsstrategier, du kan anvende i din…
For nylig er to fænomener opstået på arbejdsmarkedet, der relaterer sig til holdningerne hos nutidens…