Hvor mange ganger har du sett utviklere og testere krangle om hvordan en bestemt funksjon skal fungere? Hva med de forvirrede ansiktsuttrykkene til utviklere som ikke var sikre på hvordan de skulle bygge funksjonen du hadde bedt om? Begge deler er ganske vanlige problemer i programvareverdenen, og heldigvis har du et kraftig verktøy i arsenalet ditt for å løse dem – akseptansekriterier.
I denne veiledningen skal jeg bryte ned hva dette formatet for å dokumentere krav innebærer, forklare hvilken rolle det spiller innen produktledelse, og vise deg hvordan du skriver gode akseptansekriterier.
Innholdsfortegnelse
Hva er formålet med å skrive akseptansekriterier?
Hvordan bør velskrevne akseptansekriterier se ut?
Vanlige formater for akseptansekriterier
Hva er akseptansekriterier
(og hvilken plass har de innen smidig/Scrum?)
I smidig metodikk er et akseptansekriterium den minste enheten av et funksjonelt krav eller et designkrav som smidige produktledere (eller forretningsanalytikere) legger til i brukerhistoriene sine for å kommunisere tydelig de ulike tilstandene og den forventede atferden til funksjonene teamet planlegger å bygge.
Teknisk sett kan du bruke akseptansekriterier hvor du vil. Tradisjonelt er de imidlertid en del av brukerhistorier, som er komponenter i smidige epos.
For å forstå akseptansekriterier bedre skal vi først friske opp hukommelsen og gå gjennom elementene i dette hierarkiet for å se hva hvert av dem brukes til.
Epos
Epos er oppgaver som inneholder funksjonelle og ikke-funksjonelle krav på høyt nivå for en stor funksjon eller en gruppe funksjoner som er knyttet til hverandre. Vanligvis dekker et epos et helt bruksområde for kundene dine og inneholder alle de underliggende funksjonene og egenskapene du må implementere for å dekke det aktuelle bruksområdet.
Se for deg at du var en del av produktteamet hos Spotify, og at du ønsket å utvide bruken av appen ved å legge til et nytt bruksområde for personer som er på farten og ikke har tilgang til internett.
For å dekke dette bruksområdet kan du vurdere å legge til en ny, omfattende funksjon kalt «frakoblet modus for Spotify». Den kan bli et epos i produktkøen din, med alle de overordnede kravene for å la brukerne lytte til musikk uten nettilgang, samt flere brukerhistorier med kravene til bestemte deler av denne funksjonen.
Brukerhistorier
Brukerhistorier er mindre i omfang og representerer én enkelt, avgrenset funksjonalitet innenfor eposet. De er små arbeidsoppgaver som det smidige teamet kan forplikte seg til å levere i løpet av én iterasjon.
Et av de viktigste kjennetegnene ved en brukerhistorie er at funksjonaliteten den representerer, skal være komplett og potensielt kunne tas i bruk.
Hvis du for eksempel bygger en app for lagring av filer på nettet og vil la brukerne gi nytt navn til filene de har lastet opp, må du arbeide både på klientsiden (brukergrensesnittet og brukeropplevelsen ved å gi filen nytt navn) og på serversiden (lagring av det nye navnet).
For at funksjonen skal være komplett og brukbar, må du fullføre begge oppgavene og koble sammen delene på klientsiden og serversiden. Teamet ditt skal gjøre alt dette innenfor rammen av én brukerhistorie.
Hvis du bare skulle utføre arbeidet på serversiden, ville oppgaven ikke vært en ordentlig brukerhistorie, siden den ville inneholde en leveranse som ikke er komplett og brukbar.
For å fortelle utviklingsteamet hvordan funksjonen skal se ut og oppføre seg, skriver produkteiere akseptansekriterier for brukerhistorien.
Have an account? Log In
Akseptansekriterier for brukerhistorier
Til slutt har vi de minste elementene i hierarkiet for krav til programvareprodukter – akseptansekriteriene. De representerer individuelle bruksscenarioer for funksjonaliteten eller informasjonsbiter som utviklingsteamet vil anse som viktige ved implementeringen av brukerhistorien.
I eksempelet ovenfor kan et akseptansekriterium være at det åpnes et tekstfelt med filnavnet forhåndsutfylt dersom brukeren klikker på knappen ✏️Gi nytt navn på filen de har lastet opp.
Definisjonen på ferdig (ja, den er forskjellig fra akseptansekriterier!)
Noen ganger vil produkteiere (særlig de som er relativt nye i denne Scrum-rollen) forveksle definisjonen på ferdig med akseptansekriterier.
For å være ærlig var dette ganske forvirrende for meg i begynnelsen også, fordi begge deler er «kriterier for å kontrollere om funksjonen er komplett».
Den eneste forskjellen er at definisjonen på ferdig representerer fullstendighet når det gjelder teamets utviklingsprosesser.
Mens akseptansekriteriene representerer funksjonelle krav (hvordan funksjonen skal se ut og fungere).
Dette betyr at definisjonen på ferdig vil forbli den samme for alle historiene teamet implementerer, med mindre de bestemmer seg for å gjøre endringer i den under retrospektivene. Akseptansekriteriene er derimot unike for hver historie, ettersom de forklarer hvordan funksjonen skal fungere.
Merk: Noen produktstyringsverktøy lar deg ha både definisjonen på ferdig og akseptansekriterier i historiene dine.
Nå som vi husker hva epiker og historier handler om, og hvordan akseptansekriterier henger sammen med dem, kan vi gå videre og forstå hvorfor produkteiere skriver akseptansekriterier i utgangspunktet.
Hva er hensikten med å skrive akseptansekriterier?
Kan jeg bare skrive en beskrivelse av en brukerhistorie på den måten jeg ønsker, uten å inkludere akseptansekriterier? Hva er egentlig fordelen med å skrive akseptansekriterier?
Selvfølgelig kan du skrive historiene dine slik du ønsker. Jeg anbefaler imidlertid at du bruker akseptansekriterier som en måte å formulere kravene dine på, ettersom dette formatet har en rekke fordeler. Her er et par du bør vurdere.
De oppmuntrer til atferdsdrevet tenkning
Hvis du velger BDD-formatet for akseptansekriterier (mer om det senere), vil akseptansekriteriene beskrive kundenes reise når de bruker den aktuelle funksjonen.
Det fine med denne tilnærmingen er at du flytter tankegangen bort fra tørre tekniske krav og begynner å se på funksjonen fra brukerens perspektiv. På denne måten kan du se for deg hva de opplever og føler når de samhandler med funksjonen din.
Det er svært vanlig at produkteieren forstår at funksjonaliteten de har sett for seg, ikke er den beste når de ser på den fra brukernes perspektiv.
Jeg har også opplevd dette flere ganger. Da jeg for eksempel utarbeidet krav til en redigeringsfunksjon for matematiske formler (den var en del av et SaaS-produkt for finansanalyse som vi utviklet på den tiden), ønsket jeg at redigeringsprosessen skulle se slik ut:
- En redigeringsknapp ved siden av formelen.
- Hvis man klikket på redigeringsknappen, skulle formelfeltet bli redigerbart og vise knappene ✅ Lagre og ❎ Avbryt .
- Hvis man klikket på en av dem, skulle redigeringsmodusen avsluttes, og enten den nye, lagrede versjonen eller den gamle versjonen av formelen skulle vises der, avhengig av brukerens valg.
Denne atferden virker logisk, ikke sant?
Jo, men ikke før jeg begynte å skrive ned scenarier for analytikere som brukte den, og oppdaget en betydelig brukervennlighetsfeil. Analytikerne finjusterer vanligvis formelen ved å gjøre små endringer i den og se på beregningsresultatet, helt til de får formelen de ønsker.
Måten jeg hadde sett for meg at redigeringen skulle fungere på, ville vært svært irriterende for målbrukerne mine, ettersom de måtte gå inn i og ut av redigeringsmodusen 20–30 ganger etter hverandre. Så snart jeg innså feilen, endret jeg derfor raskt akseptansekriteriene og ba om at det skulle bygges en redigeringsfunksjon for formler der man kunne gjøre endringer i sanntid.
De bidrar til å skape én felles kilde til sannhet
Som en «nybegynner» innen produktledelse var min største utfordring å kommunisere produktkrav til personer med ulike fagområder eller til og med ulike team. Problemet var at hver enkelt av dem forsto kravene forskjellig, og kommunikasjonen mellom dem ble et utydelig kaos.
Det var da en erfaren produktleder foreslo at jeg skulle ta i bruk konseptet om én felles kilde til sannhet ved å formulere produktkravene mine på en svært tydelig måte (dette er noe KI i kravinnsamling kan bidra til), kommunisere dem til alle og be dem basere arbeidet sitt kun på det som sto skrevet der.
Det ble en stor suksess, ettersom alle hadde samme forståelse av hvordan funksjonen skulle fungere, og hvis det oppsto uenigheter, gikk de tilbake til kravet.
Akseptansekriterier er en flott måte å skape én felles sannhetskilde på, ettersom de beskriver funksjonen på en tydelig og lettlest måte og har høy detaljgrad (slik de bør ha for å dekke alle de viktigste detaljene ved funksjonen).
De forbedrer kvaliteten på akseptansetesting
For programvareingeniører fungerer akseptansekriteriene som produktkravene de skal følge når de bygger funksjonen. For kvalitetsteamet ditt har akseptansekriteriene derimot et par ekstra funksjoner:
De bidrar til å prioritere testtilfeller. Hvis programvaretestteamet ditt har mange testtilfeller for funksjonen, og det ikke er nok tid til å gå gjennom alle, vil de prioritere og kjøre testscenarioene som samsvarer med akseptansekriteriene først, ettersom de beskriver de mest kritiske brukerflytene.
De fungerer som en akseptansesjekkliste. Dette gjelder både QA-team og produkteiere som må godkjenne funksjonen. Akseptansekriteriene fungerer, som navnet tilsier, som en sjekkliste for å avgjøre om funksjonen er bestått eller ikke bestått. Hvis ett eller flere av akseptansekriteriene ikke er oppfylt, vil QA-teamet gjenåpne saken og be utviklingsteamet om å legge til den manglende funksjonaliteten.
For å oppsummere er akseptansekriterier uvurderlige verktøy for produkteiere som skal kommunisere produktkrav på en god måte. Men hvordan skriver man gode akseptansekriterier? Det skal jeg hjelpe deg med nå.
Hvordan bør velskrevne akseptansekriterier se ut?
Kvaliteten på akseptansekriteriene du skriver, vil ha direkte innvirkning på kvaliteten til funksjonene teamet ditt leverer. Med en tydelig forståelse av hva som skal bygges og hvordan det skal testes, vil teamet ditt bygge funksjonen slik du så for deg, med færrest mulig problemer.
For å bli god på å skrive akseptansekriterier må du være oppmerksom på følgende.
Tydelighet
Den største synden en produkteier kan begå, er å skrive uklare og vage akseptansekriterier. Du kan glemme tanken på en felles forståelse når folk kan tolke det du har skrevet på flere måter.
For å se hvor stor forskjell det utgjør, skal jeg vise deg et eksempel.
Hva forsto du av denne setningen? Kan du fortelle meg hvordan minibanken skal bruke korttypen til å avgjøre om den skal autentisere brukeren eller ikke? Skal minibanken autentisere brukeren hvis alle disse kriteriene er oppfylt samtidig, eller er det nok å oppfylle bare ett av dem?
Hvis du gir dette akseptansekriteriet til ingeniørene dine, vil de overøse deg med spørsmål og be deg være tydeligere i kravene dine. La oss nå gjøre det bedre.
Ser mye bedre ut, ikke sant? Med dette akseptansekriteriet har vi også besvart alle spørsmålene ovenfor. Minibanken må støtte korttypen brukeren har satt inn, og alle tre kriteriene må være oppfylt samtidig for at minibanken skal gjennomføre autentiseringen.
Eksperttips: Gjør akseptansekriteriene dine SMARTe (spesifikke, målbare, oppnåelige, relevante og testbare). Ja, jeg har endret det siste punktet til testbart, ettersom dette er en viktig egenskap ved effektive akseptansekriterier.
Lesbarhet
I tillegg til å unngå vaghet i akseptansekriteriene bør du også holde dem enkle og unngå fancy uttrykk eller komplisert engelsk.
Jeg er sikker på at du har et team med svært velutdannede stjerner som enkelt kan lese og forstå de mest avanserte og komplekse ordene og uttrykkene i det engelske språket, men du ønsker egentlig ikke å kaste bort den kognitive kapasiteten deres på å avkode tekstene dine.
Så i stedet for dette.
Si dette.
Jeg antar at du ikke engang gadd å lese det første akseptansekriteriet grundig, siden du heller ikke ville kaste bort tiden og hjernekraften din!
Dekning av tilfellene
Det er detaljene som avgjør. Noen ganger innser du at du har oversett et vanskelig tilfelle i funksjonen din svært sent i utviklingsfasen, og må opprette en oppfølgingsoppgave for forbedring eller til og med gjøre hele arbeidet på nytt.
Høres kjent ut, ikke sant?
Jo flere tilfeller du tar hensyn til i akseptansekriteriene på forhånd, desto mindre er sjansen for at du vil møte dette scenariet med oppgavene i arbeidskøen.
La oss nå se på akseptansekriteriene nedenfor.
Ser du noe merkelig her? Ved første øyekast er kravet tydelig: Du legger inn e-postadressen, trykker på send, og personen får tilgang. I virkeligheten har vi ikke tatt hensyn til mange tilfeller her:
- Hvis e-postadressen allerede finnes i listen over brukere som har tilgang til dokumentet, bør du kanskje vise en feilmelding som forteller brukeren om dette.
- Du sender en invitasjons-e-post til brukeren, så det kan kanskje være nyttig å vise om vedkommende har godtatt invitasjonen eller ikke i den delte listen.
- Hvis vedkommende ikke har godtatt invitasjonen, kan det kanskje være nyttig å legge til en knapp for «send invitasjon på nytt».
Det finnes også negative tilfeller der du avklarer hvordan funksjonen skal oppføre seg når noe er tomt, eller når det har oppstått en feil.
Aktiv bruk av visuelle hjelpemidler
Var akseptansekriteriene jeg delte ovenfor helt tydelige for deg? Da jeg snakket om feltet «Legg til personer og grupper», forsto du tydelig hva det dreide seg om?
Noen ganger er ikke ord nok til å gi teamet ditt klarhet i kravene, og det er bedre å vise dem enn å fortelle om dem. La meg nå forbedre disse akseptansekriteriene litt.
Har jeg rett i å anta at du enkelt ville ha forstått hva jeg snakket om med disse akseptansekriteriene hvis du så bildet og kommentarene mine side om side? Det tror jeg.
Det dekker altså «akseptansekriteriene» for akseptansekriterier – la oss nå se på de ulike typene og formatene produktteam bruker for dem.
Vanlige formater for akseptansekriterier
Jeg må være ærlig med deg. Jeg bruker sjelden det samme formatet i alle brukerhistoriene mine. Grunnen er at ulike formater for akseptansekriterier passer godt til ulike bruksområder, og det er ikke alltid lurt å tvinge seg selv til å bruke det samme formatet hver gang.
Derfor velger jeg formatet basert på historien og hvilken type informasjon jeg ønsker å skrive i akseptansekriteriene.
La oss nå se på noen av de vanligste formatene og eksempler på tilhørende akseptansekriterier.
BDD-format
BDD står for atferdsdrevet utvikling, og er et rammeverk som oppmuntrer programvareutviklere og medlemmer av produktteam til å definere krav basert på hvordan sluttbrukerne vil samhandle med funksjonen.
Som en måte å skrive krav basert på brukerens atferd på, følger akseptansekriteriene for BDD denne bestemte malen:
Gitt: Forutsetningen for det spesifikke scenariet for brukerens atferd.
Når: Handlingen brukeren utfører.
Så: Resultatet av handlingen.
Hvis du for eksempel ville forklare hvordan uttaksfunksjonen i en minibank fungerer, ville akseptansekriteriene dine sett slik ut:
Akseptansekriterier av typen gitt/når/så er nyttige når du ønsker å skape empati for brukernes behov i teamet ved å legge vekt på brukerens perspektiv.
More Articles
Sjekklisteformat
I motsetning til BDD-formatet (også kalt «scenarioorientert» format) viser ikke dette formatet sluttbrukerens perspektiv. I stedet handler det mer om å forklare de bestemte reglene som funksjonens forretningslogikk skal følge (det alternative navnet på dette formatet er «regelorientert»). Slik ser de ut.
Dette formatet passer best når logikken du ønsker å forklare, er kompleks, fordi det hjelper deg med å bryte den ned i flere små regler som er enklere å forstå og implementere.
Flytformat
Dette er sannsynligvis formatet jeg bruker mest.
Flytformatet ligner på BDD-formatet, siden det også viser brukerens perspektiv. I motsetning til BDD håndhever det imidlertid ikke en streng struktur (Given/When/Then). Du står derfor fritt til å beskrive trinnene brukeren tar, på den måten du ønsker.
Slik ville registreringsprosessen sett ut med dette formatet.
Flytformatet vil være det beste alternativet hvis du ønsker å skape empati med brukerne (akkurat som med BDD), men egentlig ikke ønsker å følge en streng struktur.
Sørg for at alle er på samme side med akseptansekriterier
Akseptansekriterier er kraftige verktøy i hendene på produkteiere. De gjør det mulig for dem å etablere én felles kilde til sannhet og sørge for at teammedlemmene holder seg på linje med visjonen deres for denne funksjonen.
Hvis du vil ha flere veiledninger som denne og andre flotte ressurser for produktfolk, kan du abonnere på nyhetsbrevet vårt!
