Hvordan skrive bedre brukerhistorier med agurker (mal inkludert)

Brukerhistorier er en smidig teknikk for å definere produktfunksjonalitet og krav. De fokuserer på å fortelle en historie for en handling en bruker vil ta og hva forventningene er når de lykkes. Konseptet med brukerhistorier er mye brukt, men å fortelle gode historier kan være ganske vanskelig.

Brukerhistorier har imidlertid fått litt av en hit de siste årene, siden de er små overforenklinger og mangler empati for brukeren.

Gode ​​nyheter – det finnes en bedre måte! De kalles agurker, men i motsetning til sylteagurken, er de ikke her for å gjøre livet ditt. (Med mindre du er en sylteagurk-elsker, antar jeg!) 🥒

TL;DR

Hvis du har det litt travelt, her er TL;DR (selv om jeg vil oppfordre deg til å fortsette å lese for å få tilgang til malene!)

• Brukerhistorier fokuserer på brukeren, ikke produktet.
• Skisser personlighetene dine for å legge til kontekst.
• Legg til empati i historiene dine for å forstå handlinger og motivasjoner.
• Agurker: en bedre måte å skrive historier på.
• Bruk agurk til å fokusere på resultater, ikke bare utganger.

Hva er brukerhistorier?

Brukerhistorier er korte, enkle beskrivelser av en løsning som teamet ditt har kommet opp med, fortalt fra perspektivet til personen som spiller ut interaksjonen. De er en del av et større epos som beskriver det faktiske problemet som skal løses og hvorfor du løser det.

Det operative ordet her er bruker , som betyr at en brukerhistorie setter fokus på brukeren, ikke produktet.

En brukerhistorie fokuserer vanligvis på tre områder:

• Som en ( hvem )
• jeg vil ( hva )
• Så det ( hvorfor )

Dette blir vanligvis fulgt av akseptkriterier , som definerer hvordan du vet om interaksjonen er vellykket.

Hvem: Bruke personas for å skissere brukerhistorier

Hvis du ennå ikke har definert eller forstått brukerne dine, bør du egentlig ikke skrive brukerhistorier. Start med litt oppdagelse først, kartlegg en kundereise, og lag relevante brukerpersonas som vil hjelpe deg med å definere disse historiene videre.

En persona kan hjelpe deg med å forstå og gi kontekst til “hvem” i brukerhistorien – med andre ord hvem som utfører denne interaksjonen.

Dette er viktig siden du uunngåelig vil ha forskjellige kundesegmenter, roller og tillatelser involvert, så det er viktig å definere disse interaksjonene for å imøtekomme de forskjellige typene brukere.

Hva: Interaksjoner med brukerhistorie

«Hva» i en brukerhistorie fokuserer på selve interaksjonen. Det vanskelige her er å sørge for at “hva” ditt fokuserer på hva brukeren må gjøre, i motsetning til hva brukeren vil gjøre, og det er her den typiske historiemalen faller litt fra hverandre.

For å legge til litt empati til selve historien , er det viktig å fremheve hvordan brukeren kan føle seg når han samhandler med en bestemt handling.

For eksempel er det ingen som ønsker å skrive inn et komplisert passord med stor bokstav, spesialtegn og en minimumslengde – men de vet at de skal. I dette tilfellet er det noe brukeren er pålagt å gjøre.

Hvorfor: Årsaken til brukerhistoriehandlingen

Den tredje delen av brukerhistoriemalen er ‘hvorfor’ – det vil si hvorfor brukeren ønsker å (eller er pålagt å) utføre en bestemt handling.

Gå tilbake til vårt forrige eksempel på å skrive inn passord:

Som administrator er jeg pålagt å lage et komplisert passord, slik at kontoen min er sikker.

Vi forstår nå hvem, hva og hvorfor av historien – men det er et problem her. Dette mangler fortsatt empati og kontekst fordi la oss være ærlige, ingen vil at kompliserte passord skal være et krav, men vi vil alle ha sikre kontoer.

Når du tester dette, ville QA-teamet rett og slett stoppe med å sjekke om passordet er sikkert, ikke om prosessen var frustrerende for brukeren.

Skriv inn Gherkin-brukerhistoriemalen

Agurker er en måte å legge til brukerhistorier og gi et fullstendig scenario som vil hjelpe utviklere og testere å forstå både resultatet og resultatet av en bestemt brukerinteraksjon.

1. Scenario – oppførselen du skal beskrive
2. Given — begynnelsestilstanden til scenariet
3. When — en spesifikk handling som brukeren utfører
4. Then – et testbart utfall, vanligvis forårsaket av handlingen i When
5. And — dette fortsetter en av de tre andre operasjonene om nødvendig

Ta passordscenariet som er beskrevet tidligere:

1. Når du angir et passord (Scenario ),
2. Given at jeg er en kontoadministrator,
3. WhenJeg skriver inn et passord i passordfeltet,
4. ThenJeg bør advares om passordkravene,
5. And Jeg burde få lov til å gjøre rettelser med en gang,
6. Then at jeg kan opprette en sikker konto.

Vi har nå et fullstendig bilde av hvem som utfører den konkrete handlingen, og hvilke krav som stilles til akseptkriteriene, og teamet vet hvilke potensielle frustrasjoner det kan være slik at de kan sørge for at prosessen flyter mer smidig.

Generelt er produktsjefen eller produkteieren ansvarlig for å skrive ut Gherkin-historiene, og dermed skape bedre kommunikasjon mellom resten av teamet og sørge for at alle fokuserer på resultater, ikke bare resultater.

Hva er dine favorittmåter å skissere historier på? Gi meg beskjed! ✌️