En snabbguide till acceptanskriterier för user stories

I det här inlägget får du lära dig ett enkelt sätt att få med teamet på den här metoden: genom att anteckna under refinement-diskussionerna.

Men låt oss först prata om varför acceptanskriterier är viktiga. Du kan förstås också hoppa direkt till anteckningsmetoden i slutet.

Vad är acceptanskriterier?

Agile-team använder en backlog med arbete. Poster i backloggen kan skrivas i formatet user story. En user story är en kort beskrivning av arbetet som beskriver:

• Vem som behöver resultatet av arbetet

• Vilket problem som ska lösas

• Varför det behöver lösas

Detta ”vem, vad och varför” kallas ibland för Cohn story format.

Att formulera arbetsuppgifter som user stories är helt enkelt ett tankeverktyg. Det är inte obligatoriskt att använda. Använd det när det finns ett tydligt problem för en systemanvändare att lösa. User stories hjälper teamet att diskutera och skapa en gemensam förståelse för problemet som ska lösas.

Varför lägga till acceptanskriterier i user stories?

En viktig anledning att använda user stories är att skapa ett gemensamt språk mellan verksamheten och utvecklarna. User stories beskriver behovet, problemet, på ett sätt som alla ska kunna förstå och diskutera.

Att använda user stories fokuserar diskussionen på att förstå problemet. Teamet kan undvika att gå för djupt in i tekniska diskussioner som kan utestänga verksamhetsintressenter utan teknisk bakgrund. Med en gemensam förståelse för behovet kan teamet bättre definiera vilken typ av lösning som behövs för att lösa det.

En user story består av tre separata delar:

1. Titel

2. Beskrivning (vem, vad och varför)

3. Lista med acceptanskriterier

Titeln och beskrivningen definierar varför problemet behöver lösas och vem som kommer att ha nytta av det.

Men acceptanskriterierna definierar egentligen vad user storyn handlar om.

Om du inte använder acceptanskriterier riskerar du att:

• inte implementera något som behövs (vilket kan innebära att du kallar något klart, för att senare upptäcka att det behöver göras om)

• implementera något som inte behövs

• inte ha en helt gemensam förståelse för vad som behövs

• göra en felaktig uppskattning av arbetsinsatsen

Alla dessa risker kan leda till slöseri. Teamet kan behöva göra om något många gånger för att få det rätt, eller så kan arbetet vara för stort för att hinna slutföras under en sprint.

Undvik frågan ”Varför tar det så lång tid?”

Ofta undrar Product Owner varför utvecklingen tar så lång tid. Det skulle ju vara enkelt att bygga funktionen. Den ursprungliga uppskattningen var en eller två veckors arbete. Nu har det gått mer än en månad. Vad är det som händer?

Det är alltför lätt för utvecklingsteamet att lägga till för många saker i ett försök att täcka in allt. Ibland vill utvecklare skapa en överdimensionerad lösning, när ett betydligt enklare angreppssätt vid en granskning hade varit tillräckligt. Detta slöseri med tid och arbete hade kunnat undvikas genom att diskutera acceptanskriterier – de är utmärkta för att avgöra vad som inte behövs.

Ett exempel: Djävulen ligger i detaljerna

Här är ett annat vanligt problem när acceptanskriterier inte används: funktioner utvecklas utan att man fullt ut tar hänsyn till allt som faktiskt behövs. Låt oss titta på ett exempel.

Exempel på user story: byta lösenord

En användare:
Jag vill byta mitt lösenord så att jag kan använda systemet.

Den här user storyn beskriver ett problem: systemet bör erbjuda användare ett sätt att byta lösenord. En lösning kan vara ett alternativ för att ”byta lösenord” någonstans, följt av en vy eller ett popup-fönster där användaren kan byta lösenord.

Enkelt, eller hur? Ska vi gå vidare och implementera det eller uppskatta arbetsinsatsen för implementeringen?

Acceptanskriterier synliggör den verkliga komplexiteten

Låt oss diskutera några möjliga acceptanskriterier. Här är några som kan vara aktuella:

• Lösenordet är minst 8 tecken långt

• Lösenordet måste innehålla minst ett specialtecken

  • Lista över specialtecken som kontrolleras

• Lösenordet måste innehålla minst en gemen och en versal bokstav

• Lösenordet måste anges i två separata fält

• Båda lösenordsfälten måste matcha för att registrering ska vara möjlig

• Slutanvändaren visas en indikator om lösenordet inte är tillräckligt starkt

• Styrkeindikatorn ska ändras efter varje ändring i lösenordsfältet

• Användaren får information om varför registrering inte är möjlig

  • Lösenordet måste vara minst 8 tecken långt

  • Lösenordet är inte tillräckligt starkt: lägg till specialtecken eller siffror

  • Fyll i alla obligatoriska fält – [fält med saknad information]

• Registrering är endast möjlig om lösenordet är tillräckligt starkt

• Registrering är endast möjlig om alla andra obligatoriska fält är ifyllda

• Obligatoriska fält är tydligt markerade

Utan att prata om acceptanskriterier skulle en enkel story som i vårt exempel kunna implementeras, men logiken bakom sidan skulle inte vara klar. Problemen skulle upptäckas senare och teamet skulle behöva återvända till sidan för att göra den användbar och bra för användaren.

Uppskatta arbetsinsatsen först efter att ni har listat acceptanskriterierna

Genom att diskutera exakt vad som behöver göras kan teamet nå en gemensam förståelse. Först när detta är gjort bör ni uppskatta arbetsinsatsen. Utan acceptanskriterier kan man tänka sig att det bara tar några timmar eller en story point att skapa sidan. Med alla acceptanskriterier kan uppskattningen ändras till ett par dagar eller 3–5 story points.

De främsta fördelarna med att använda acceptanskriterier

De främsta fördelarna med acceptanskriterier är:

• En gemensam förståelse för vad som behövs

• Mer träffsäkra uppskattningar av arbetsinsatsen

• Mer träffsäkra uppskattningar av velocity

• Bättre åtagande för sprinten

• Enklare att identifiera för stora stories

• Enklare att dela upp för stora stories i mindre stories

Så kommer du enkelt igång med acceptanskriterier: dokumentera diskussionen

Den här metoden är avsedd för team som inte har någon tidigare erfarenhet av att använda acceptanskriterier.

För den här processen behöver ni någon som antecknar eller fungerar som sekreterare. Om ni har en Scrum Master kan hon ta den rollen.

1. Öppna user storyn så att alla kan se den (mycket viktigt – ni vill att alla direkt ska se vilken typ av anteckningar som görs)

2. Börja ställa frågor, kommentera och ge svar – vad innebär den här storyn?

3. Den som antecknar tolkar frågorna och kommentarerna och skriver omedelbart ned dem som punktlista under storybeskrivningen. OBS: I det här skedet är det viktigt att den som antecknar bara skriver in alla kommentarer och frågor i beskrivningen, utan att invänta bekräftelse eller beslut. Målet är att dokumentera diskussionen. Fortsätt så i några minuter.

4. Efter några minuter, eller när diskussionen börjar avta, tittar ni på punktlistan. Punkterna i listan är era möjliga acceptanskriterier. Nästa steg är att kontrollera om någon inte håller med om någon av punkterna. Om så är fallet, fokusera diskussionen på det ämnet.

5. Avslutningsvis kan ni undersöka några frågor:

   1. Behövs alla dessa?

   2. Finns det några som verkar motsägelsefulla?

   3. Saknas något uppenbart?

   4. Har vi för många acceptanskriterier? Om ni vanligtvis har fler än 10 är det en indikation på att storyn kan delas upp i två mindre stories.

Börja med att göra teamet mer bekant med acceptanskriterier – utveckla arbetssättet senare

Det kan sammanfattas väldigt enkelt – anteckna bara och dokumentera diskussionen. Oroa er inte för formella saker som att ”formulera acceptanskriterier som frågor”. Det kan ni göra senare, om ni vill.

Mervärdet med dokumenterade punkter och att få teamet att känna sig bekvämt med att lägga till dem i varje story är viktigare än att följa sådana formella regler.