hur man skriver acceptanskriterier: exempel och bästa praxis

här på Mobindustry arbetar vi med en smidig inställning. Det innebär att vi använder smidiga komponenter som användarhistorier och acceptanskriterier. Högpresterande team och organisationer har dessa komponenter i sina produktbakgrunder, och de vet hur man skapar dem och använder dem effektivt.

om din produkt eftersläpning saknar användarhistorier och acceptanskriterier — eller om de inte är klart definierade — riskerar du att dina förväntningar inte konvergerar med verkligheten., Användarhistorier och acceptanskriterier är ansvariga för att representera hur slutanvändaren kommer att använda din app och hur ditt utvecklingsteam ska utföra varje utvecklingsuppgift. När vi börjar arbeta med en ny produkt samarbetar vårt team med kunden för att definiera användarhistorier.

en användarhistoria är en kort, enkel beskrivning av en produktfunktion ur en persons perspektiv som vill använda den funktionen. Användar berättelser används för att definiera produkten eftersläpning i en smidig utveckling arbetsflöde.,

produktstocken är i huvudsak en samling användarhistorier som informerar den funktionella specifikationen och utvecklingen av funktioner för en viss produkt eller tjänst. Användarhistorier består av tre delar: en persona av användaren berättelsen skrivs för, en beskrivning av funktionen användaren Kräver och en förklaring av behovet funktionen uppfyller.

Så här skriver du en användarhistoria:

som (användare) vill jag ha en (funktion) så att jag kan (tillgodose ett behov).

Låt oss ta en titt på hur en användarhistoria kan se ut., Vi tar Airbnb som ett exempel. Låt oss föreställa oss hur en typisk användarhistoria kan leta efter en produkt som Airbnb.

”som användare vill jag söka efter en destination så att jag kan boka boende i en främmande stad.”

definition av acceptanskriterier

nu måste vi se till att användarhistorier är korrekt färdiga och uppfyller kundens krav.

acceptanskriterier är de villkor som en programvaruprodukt måste uppfylla för att accepteras av en användare, kund eller, när det gäller systemnivåfunktionalitet, det förbrukande systemet.,

acceptanskriterier är en uppsättning uttalanden, var och en med ett tydligt pass / felresultat, som kan mätas och ange både funktionella och icke-funktionella krav.

skrivning av acceptanskriterier är viktigt inte bara för att fastställa vad kunden förväntar sig av produkten utan för utvecklingsprocessen. Naturligtvis ser olika människor samma problem från olika vinklar. Väldefinierade acceptanskriterier ger en enhetlig bild av den funktionalitet du planerar att implementera.,

vem som helst ska kunna gå upp till en Scrum board, ta en produkt eftersläpning objekt, läsa acceptanskriterier, och tydligt se allt som behöver fyllas i för att just objektet ska flyttas till den färdiga kolumnen. Acceptanskriterier berätta vad som behöver göras för en viss del av en produkt som ska vara klar.

Varför behöver vi acceptanskriterier?,

• definiera gränser. Acceptanskriterier hjälper utvecklingsteamet att definiera gränserna för en användarhistoria. De fungerar som en form av bekräftelse på att appen fungerar som förväntat, vilket innebär att användarhistorien är klar.
• nå konsensus. Acceptanskriterier tillåter utvecklingsteamet att vara på samma sida som klienten. De informerar utvecklingsteamet om exakt vilka villkor som måste uppfyllas och se till att kunden vet vad man kan förvänta sig av ansökan.
• effektivisera acceptanstest., Acceptanskriterier är grunden för användarhistoria acceptanstest. Varje godkännandekriterium bör testas oberoende och ha tydliga scenarier för framgång eller misslyckande.
• planering och uppskattning. Med acceptanskriterier kan du distribuera användarhistorier över uppgifter så att de är korrekt bedömda och schemalagda.
• beskriver negativa scenarier. Acceptanskriterier kan kräva att systemet identifierar ett svagt lösenord och förhindrar att en användare fortsätter, till exempel., Att ange ett felaktigt lösenordsformat är ett exempel på ett negativt scenario där en användare anger felaktiga data eller uppträder oväntat. Acceptanskriterier identifiera dessa scenarier och förklara hur systemet ska reagera på dem.

vem skriver acceptanskriterier?,

att skriva acceptanskriterier bidrar till att skapa en gemensam förståelse mellan produktägaren och utvecklingsteamet när det gäller att lösa en kunds problem eller skapa produktfunktioner. Eftersom acceptanskriterier avser kunden och laget, bör de skrivas antingen av kunden eller en teammedlem.

hos Mobindustry skriver våra affärsanalytiker alla acceptanskriterier för användarhistorier. Affärsanalytiker förstår kundens behov och vad utvecklare behöver veta för att uppfylla projektkraven.,

acceptanskriterier dokumenteras och bekräftas före projektets början, eftersom teamet och kunden måste komma överens om vilka resultat som kommer att uppfylla kundens krav.

exempel på användarhistorier med acceptanskriterier

nu när du har en tydlig förståelse för vilka användarhistorier och acceptanskriterier är, låt oss ta en titt på några exempel.,

exempel 1

användarhistoria: som användare vill jag kunna registrera mig i tjänsten så att jag kan börja handla online.

acceptanskriterier:

• användare kan bara skicka in ett formulär genom att fylla i alla obligatoriska fält.
• Det e-postmeddelande som användaren tillhandahåller får inte tillhandahållas av en gratis e-posttjänst.
• inlagor från samma IP kan endast göras tre gånger inom 30 minuter.
• användare får e-postmeddelanden efter att ha registrerat sig.,

exempel 2

användarhistoria: som användare kan jag komma åt en anmälan på min enhet omedelbart efter att ha fått den.

acceptanskriterier:

• svepa / knacka på en anmälan tar användaren direkt till meddelandet.
• Visa visar konversation — om det nya meddelandet var ett svar visas det ovanför originalet.
• meddelandeantalet uppdateras.
• ett meddelande markeras läsa när det visas.

7 tips om att skriva bra acceptanskriterier

acceptanskriterier är inte lätta att skriva., Trots det enkla formatet är det en utmaning att skriva texten. Här är sju tips som hjälper dig att undvika vanliga misstag när du skriver acceptanskriterier eller att granska kriterier skrivna av en medlem i ditt team.

• Dokumentkriterier innan utvecklingsprocessen börjar. På detta sätt är laget mer benägna att fånga alla kundens behov i förväg. Ursprungligen är det tillräckligt att ställa in kriterier för ett litet antal användarhistorier för att slutföra eftersläpningar för två sprints. De dokumenterade acceptanskriterierna används sedan av utvecklare för att planera den tekniska processen.,
• gör inte acceptanskriterier för smala. Acceptanskriterier som är för specifika lämnar Utvecklare lite utrymme att manövrera. För att undvika detta, kom ihåg att acceptanskriterier bör vara ett uttryck för avsikt, inte ett slutgiltigt beslut. Dessutom kan smala acceptanskriterier inte ta hänsyn till alla användaråtgärder.
• Håll dina kriterier uppnåbara. Effektiva acceptanskriterier definierar en rimlig minsta mängd funktionalitet som du kan tillhandahålla. Men om du fortsätter att beskriva alla små detaljer finns det risk för att ditt lag kommer fastna på hundratals små uppgifter.,
• undvik alltför breda acceptanskriterier. Breda acceptanskriterier gör en användarhistoria vag. Effektiva acceptanskriterier måste skissera omfattningen av arbetet så att utvecklare kan planera och uppskatta sina ansträngningar ordentligt.
• Undvik tekniska detaljer. Kriterier för godkännande ska skrivas på ett tydligt språk. Dina intressenter och chefer kanske inte har teknisk bakgrund, så att använda vanligt språk gör kriterierna begripliga för alla.
• nå konsensus., Samma problem kan lösas på olika sätt av gruppmedlemmar och intressenter beroende på deras synpunkter. Se till att du kommunicerar dina acceptanskriterier till intressenter och gruppmedlemmar och når en ömsesidig överenskommelse.
• skrivbara acceptanskriterier. Detta kommer att ge testare möjlighet att se till att alla krav är uppfyllda och gör det möjligt för utvecklare att veta om användarhistorien är klar.,

hur man skriver acceptanskriterier

här är fem allmänna regler som hjälper dig att lösa problem med formuleringen av acceptanskriterier. Dessa regler låter dig spara värdefull tid och skapa en förståelse mellan produktägaren och utvecklingsteamet.

regel # 1: Undvik ”inte”

”inte” betyder ”under inga omständigheter” och därför kommer ingen tid att räcka för att verifiera att ett sådant villkor är uppfyllt., Om du skriver om kravet utan att använda ”inte” blir det tydligare och, viktigast av allt, verifierbart.

exempel:

användarhistoria

Gör inte: som användare vill jag inte behöva ange mitt lösenord varje gång jag öppnar mitt konto.
gör: som användare vill jag att mitt lösenord ska komma ihåg och automatiskt fyllas i så att jag kan komma åt mitt konto utan att skriva in mitt lösenord igen.

acceptanskriterier

Gör inte: systemet får inte misslyckas.
gör: systemet ska ha en tillgänglighet på minst 90%.,

undantag

Du kan använda ”inte” i acceptanskriterier för att införa en logisk invändning, till exempel ”inloggningsformuläret ska inte vara rött.”I de flesta fall kommer detta att gälla för icke-funktionella krav. I det här exemplet formulerar vi en begränsning som lätt kan verifieras om utbudet av nyanser av rött är tydligt definierat (till exempel specificerat i RGB-format).,

regel #2: Använd aktiv röst

aktiv röst är när ämnet i en mening är utövande av åtgärden. Om den enhet som ansvarar för att utföra åtgärden inte är tydligt angiven kommer det att vara oklart vem eller vad som ska utföra åtgärden, och det blir svårare för dig att kontrollera om ett krav är uppfyllt.,

exempel:

användarhistoria

Gör inte: som en online-shopper vill jag att filter ska tillämpas så att jag kan hitta vad jag vill ha.
gör: som användare vill jag använda sökfilter så att jag kan hitta objekt.

acceptanskriterier

Gör inte: kundens identitet bör bekräftas. (Det är oklart vem eller vad som är ansvarig för att bekräfta kundens identitet.)
gör: Accounting_System bör bekräfta Customer_Indentity. (Observera att definitionerna av termerna ”Accounting_System ” och” Customer_Indentity ” ska läggas till i ordlistan.,)

regel #3: Undvik att använda pronomen (särskilt odefinierade)

använd substantiv istället för pronomen när du hänvisar till objekt som refereras i andra krav. Pronomen bör undvikas eftersom de kan införa tvetydighet.,

detta är särskilt viktigt när acceptanskriterier lagras i kravhanteringsverktyg (som Jira) som separata uttalanden som inte nödvändigtvis är organiserade. Använd alltid substantiv istället för pronomen och du kommer att undvika detta problem.

exempel:

användarhistoria

Gör inte: som webbplatsmedlem vill jag dela information om mig själv så att andra kan se den.
gör: som webbplatsmedlem vill jag lägga till en profilbeskrivning så att andra kan lära sig om mig.

acceptanskriterier

Gör inte: regulatorn ska skicka föraren resvägen för dagen., Det ska levereras minst 8 timmar före skiftet.
gör: regulatorn ska skicka Driver_itrary för dagen till föraren minst 8 timmar före Driver_Shift.

Regel #4: Undvik konjunktioner

konjunktioner är ord och fraser som ”och”, ”eller”, ”men” och ”samt” som kombinerar enkla meningar till komplexa., Deras användning i krav är vanligtvis ett tecken på att ett krav kan delas upp i flera separata krav.

exempel:

användarhistoria

Gör inte: som UI-designer vill jag skapa och visa ett problem så att jag vet vad jag ska testa.
gör: som UI-designer vill jag skapa ett problem så att jag vet vad jag ska testa. / Som UI-designer vill jag se ett problem så att jag vet vad jag ska testa.

acceptanskriterier

Gör inte: användaren bör antingen lita på eller inte lita på.
gör: Security_System bör kategorisera varje användare som antingen betrodd eller Not_Trusted.,

undantag

”och” ”eller” och ”inte” kan användas för att beskriva logiska förhållanden och lägga till kvalificerare.

regel #5: Undvik ouppnåeliga absolutes

ett absolut (t.ex. 100% tillgänglighet) är ouppnåeligt. Tänk på hur man kontrollerar indikatorn: kommer det att vara möjligt att bevisa att nivån på systemets tillgänglighet är exakt 100%?, Och även om ett sådant system skulle kunna skapas, har du råd med det?

Undvik orden ”Alla”, ”alltid” och ”aldrig”, eftersom kontroll av sådana absoluta krav kommer att kräva ett oändligt antal tester.

exempel:

användarhistoria

Gör inte: som resenär vill jag veta min exakta plats uppdaterad i realtid så att jag inte går vilse. (”Realtid” kan tolkas på olika sätt. Det kan till exempel ses som ett absolut (frånvaron av någon fördröjning), som inte kan uppnås och som inte är verifierbar.,)
gör: som resenär vill jag veta min exakta plats, uppdateras varje sekund, så att jag inte går vilse.

acceptanskriterier

Gör inte: systemet ska ha 100% tillgänglighet. (100% är ett absolut som inte kan nås och kan inte verifieras.)
gör: systemet bör ha en tillgänglighet på minst 98%.

snabb sammanfattning av acceptanskriterier

Vi hoppas att den här artikeln har belyst världen av acceptanskriterier och användarhistorier., Här är de viktigaste takeaways:

• acceptanskriterier är de villkor som en mjukvaruprodukt måste uppfylla för att accepteras av en användare, kund, eller när det gäller systemnivå funktionalitet, det förbrukande systemet.
• acceptanskriterier ska dokumenteras och slutföras innan ett projekt inleds, eftersom teamet och kunden måste komma överens om vilka resultat som kommer att uppfylla kundens krav.
• kom ihåg att acceptanskriterier bör vara ett uttryck för avsikt, inte ett slutligt beslut.
• effektiva acceptanskriterier definierar en rimlig minsta mängd funktionalitet.,
• god acceptans kriterier måste beskriva omfattningen av arbetet så att utvecklare kan korrekt planera och uppskatta sina ansträngningar.
• acceptanskriterier ska skrivas på vanligt språk.
• se till att du kommunicerar dina acceptanskriterier till intressenter och gruppmedlemmar och når en ömsesidig överenskommelse.
• när du skriver acceptanskriterier, undvik att använda ”inte” konjunktioner och ouppnåeliga absolutes. Formulera meningar med aktiv röst.,

om du vill skapa acceptanskriterier och användarhistorier för din mobilapp eller om du har några frågor om detta ämne, kontakta Mobindustry för ett gratis samråd.